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ABSTRACT 


In  a  peacetime  environment  of  increasing  budget  cuts 
resulting  in  reduced  manning  levels,  active  management  of 
limited  manpower  assets  is  vital  to  ensure  mission 
accomplishment  and  battle  readiness.  Manpower  analysis  is 
the  process  by  which  an  activity's  manpower  assets  are 
matched  to  or  balanced  against  authorized  billets  to 
determine  strengths  and  weaknesses  in  manning  structure. 

Manpower  analysis  must  be  performed  on  a  continual  basis 
at  all  Naval  activities.  Each  command  must  identify, 
through  manpower  analysis,  future  manning  shortfalls  and 
take  appropriate  actions  to  alleviate  them. 

This  thesis  presents  the  data  and  functional 
requirements,  and  logical  database  design  for  an  Automated 
Manpower  Analysis  and  Personnel  Management  System  (AMA/PMS) . 
Object  oriented  database  design  methodology  was  used  to 
define  data  and  functional  requirements  of  the  system. 
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I. 


INTRODUCTION 


A.  BACKGROUND 

Manpower  end-strengths,  both  military  and  civilian,  for 
the  Department  of  the  Navy,  are  authorized  annually  by 
Congress  and  reflected  in  the  Secretary  of  Defense's 
(SECDEF)  Six  Year  Defense  Program  (SYDP) .  Identification  of 
future  manpower  requirements  is  an  integral  part  of  the 
Planning,  Programming,  and  Budgeting  System  (PPBS)  process. 
Manpower  requirements  are  determined  by  force  structure, 
weapons  systems  configurations,  warfare  tasking  and  support 
thereof . 

In  a  peacetime  environment  of  increasing  budget  cuts 
resulting  in  reduced  manning  levels,  it  is  vitaj.  that 
limited  manpower  assets  be  actively  managed  to  ensure 
mission  accomplishment  and  battle  readiness.  Manpower 
analysis  is  the  process  by  which  an  activity's  personnel 
assets  are  matched  to  or  balanced  against  authorized  billets 
to  determine  strengths  and  weaknesses  in  manning  structure. 

The  activity  commander  must  be  aware,  at  all  times,  of 
how  his/her  manning  structure  (personnel  assigned)  balances 
against  the  activity's  billet  structure  (job  organization) . 
Manpower  assets  must  be  monitored  not  only  for  current 
status  but  also  for  future  required  manning  levels  based  on 
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mission  requirements  and  operational  commitments. 

Assignment  of  personnel  to  an  activity  normally  requires 
four  to  seven  months  lead-time.  Therefore,  manning 
shortfalls  cannot  usually  be  relieved  quickly  and  must  be 
planned  for  well  in  advance  to  ensure  mission  readiness. 

A  case/example  helps  illustrate  this  point.  An 
overseas,  isolated  Naval  activity  had  a  billet  authorization 
(BA)  for  a  single  Utilitiesman  (UT2)  with  a  critical  6104 
Naval  Enlisted  Classification  Code  (NEC) ,  air-conditioning 
(AC)  repair.  It  is  vital  to  mission  accomplishment  that  at 
least  two  of  the  three  air-conditioners  for  climate  control 
in  the  computer  building  be  operational  at  all  times.  The 
nearest  available  civilian  contract  AC  repair  support  was 
six  hours  automobile  drive  from  the  activity.  No  other 
military  support  was  available  at  a  shorter  distance. 

Two  weeks  before  the  assigned  UT2's  projected  rotation 
date  (PRD) ,  the  command  suddenly  realized  they  had  no  relief 
on  board  or  anyone  ordered  in  as  relief.  The  incumbent  UT2 
could  not  be  held  at  the  activity  as  his  presence  was 
required  for  onboard  relief  at  his  next  duty  station. 

Through  intervention  of  their  Immediate  Superior  in  Command 
(ISIC) ,  the  manning  control  staff  of  Commander  in  Chief 
Atlantic  Fleet,  and  the  Enlisted  Personnel  Management 
Accounting  Center  (EPMAC) ,  a  relief  was  detailed  to  and 
received  by  the  activity  two  days  prior  to  the  incumbent's 
departure . 
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Had  this  activity  performed  manpower  analysis  on,  say,  a 
monthly  basis,  they  would  have  recognized  well  in  advance  of 
the  UT2's  PRD  that  an  onboard  relief  was  critical  to  mission 
accomplishment  and  could  have  solved  the  problem  long  before 
intervention  by  senior  commands  was  required. 

On  the  other  hand;  if  performed  properly,  manpower 
analysis  can  result  in  early  identification  and  resolution 
of  potential  manning  problems  as  the  following  case 
illustrates.  This  case  is  for  a  shore  activity  with  a 
requirement  for  approximately  a  dozen  Data  Processors  (DPs) . 
These  DPs  worked  with  a  mainframe  computer  which  was  used  24 
hours  a  day  for  real-time  data  analysis.  The  computer  room 
was  required  to  be  manned  24  hours  a  day,  on  a  rotating 
basis,  by  qualified  watch-standers .  At  least  four  months  on 
the  job  training  was  required  to  qualify  an  individual  to  go 
on  the  watch  bill. 

By  conducting  manpower  analysis,  the  Division  Officer 
was  able  to  verify  the  readiness  of  his  division.  The 
majority  of  his  DPs  were  female,  limited  duty  personnel 
(because  of  pregnancy)  received  from  ships.  The  remainder 
of  his  division  were  male  and  female  permanently  assigned 
petty  officers  and  seamen. 

About  the  time  the  limited  duty  personnel  were  finished 
qualifying  for  watch,  they  were  placed  on  restricted  work 
hours  by  medical  (precluding  watch  standing  duties)  followed 
shortly  thereafter  by  maternity  leave.  Generally  these 
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individuals  did  not  return  to  the  shore  activity  at  the  end 
of  their  convalescent  leave,  but  returned  to  full  duty 
onboard  their  ships,  thereby  limiting  the  number  of 
qualified  watch  standers  to  the  few  permanent  party  DPs. 

Because  proactive  manpower  analysis  was  performed,  the 
shore  activity  was  able  to  show  precisely  the  impact  on 
current  and  future  mission  readiness  of  this  limited  duty 
assignment  policy.  Through  close  work  with  the  DP  detailing 
staff  at  Naval  Military  Personnel  Command  (NMPC) ,  this 
activity  was  able  to  have  the  number  of  limited  duty 
assignments  to  them  drastically  reduced  and  the  required 
number  of  regular  PCS  DPs  restored.' 

B .  PROBLEM  STATEMENT 

Upper  echelon  Navy  staffs  have  trained  personnel 
assigned  specifically  as  manpower  analysts.  At  the  lower 
echelon  staff  and  activity  levels,  however,  the 
responsibility  for  manpower  analysis  falls  to  the  Executive 
Officer,  Department  Heads,  and  Division  Officers  who, 
generally,  have  had  no  formal  training  in  this  process. 

Few  Naval  officers  are  formally  or  even  informally 
trained  in  the  manpower  analysis  process,  yet  this  is  a 
vital  part  of  effective  management  of  scarce  personnel 


'  By  policy,  medical  limited  duty  personnel  are  not  to  be 
counted  against  normal  BA.  However,  this  activity  found  that  the 
quantity  of  onboard  permanently  assigned  DPs  was  substantially 
below  NMP. 
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resources.  Normally,  when  an  officer  reports  for  duty  to  an 
activity,  he/she  receives  turnover/passdown  as  to  the 
mission  of  the  command  and  division/department.  This 
passdown  generally  includes  a  list  of  personnel  assigned  to 
that  work  area  and  a  description  of  the  duties  each 
performs.  Rarely  is  an  officer  given  a  copy  of  the 
authorized  billet  structure  for  his/her  division/department 
or  shown  how  the  personnel  assigned  relate  to  that  billet 
structure . 

Generally,  formal  manpower  analysis  is  performed  at  the 
higher  echelon  staff  levels,  usually  by  officers  assigned 
specifically  as  manpower  analysts.  If  manpower  analysis  is 
performed  at  the  activity  level,  it  is  usually  by  personnel 
who  happen  to  use  manpower  analysis  techniques  because  of 
previous  work  experience  in  that  area.  An  activity's 
manpower  analyst  should  have  an  understanding  of  the 
complexity  of  the  command's  operational  mission  and 
administrative  support  requirements;  how  the  billet 
structure  is  determined;  what  quantity  of  billets  are 
required  for  full  mission  readiness;  why  there  is  a 
difference  between  Billet  Authorizations  and  Billet 
Requirements;  why  a  specific  rating  mix  of  personnel  is 
assigned;  and  how  the  number  of  personnel  assigned  is 
determined.  Knowledge  of  each  of  these  areas  is  required  in 
order  to  perform  effective  manpower  analysis  at  any  activity 
level . 
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The  primary  problem  with  the  current  system  of  manpower 
analysis  employed  at  the  activity  level  in  the  Navy  is  that 
Manpower  Analysis  training  is  not  part  of  the  formal  officer 
training  program.  Most  junior  officers  (LCDR  and  below)  do 
not  know  what  a  Manpower  Authorization  (MPA)  is  or  how  to 
read  it.  Additionally,  few  officers  ever  see  an  Enlisted 
Distribution  Verification  Report  (EDVR)  or  Officer 
Distribution  Control  Report  (ODCR)  or  Manpower  Document 
until  they  reach  the  Department  Head  or  Executive  Officer 
level.  Generally,  only  those  officers  assigned  duties  as 
manpower  analysts,  such  as  Aviation  Maintenance  Officers  in 
aviation  squadrons,  are  ever  required  to  use  manpower 
analysis  documents  in  the  management  of  their  workcenter, 
division,  or  department.  Usually  officers  are  completely 
unaware  of  their  authorized  billet  structure  and  rely 
strictly  on  the  roster  of  personnel  assigned  to  them  in 
order  to  identify  workcenter  structure.  This  lack  of 
knowledge  of  manpower  analysis  documents  and  techniques 
results  in  poor  planning  for  future  manning  needs.  Formal 
manpower  analysis  is  often  not  even  done  at  a  divisional  or 
departmental  level. 

C.  OBJECTIVES 

The  general  objective  of  this  thesis  is  to  define  the 
activity  level  manpower  analysis  process  and  to  present  a 
design  for  an  automated  database  for  performing  this 
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process.  This  objective  will  be  accomplished  by  presenting 
a  functional  description  of  manpower  analysis,  fully 
defining  data  inputs  for  the  analysis  process,  and  providing 
examples  of  possible  outputs  of  the  system  used  by  various 
levels  of  a  Naval  activity.  It  is  envisioned  that 
automating  the  manpower  analysis  process  at  the  activity 
level  will  readily  accomplish  education  on  the  importance 
and  the  mechanisms  of  the  process. 

D.  RESEARCH  QUESTIONS 

The  area  of  research  is  limited  to  respond  to  four 
questions : 

1.  From  a  staff,  organizational,  and  departmental 
or  divisional  level,  what  functional  requirements 
must  be  addressed  to  support  effective  activity 
level  management  of  manpower  resources? 

2.  What  data  elements  are  required  to  evaluate  an 
activity's  manpower  profile? 

3.  What  manpower  reports  are  required  at  each 
management  level  of  an  activity  to  support  manpower 
planning  and  management? 

4.  What  additional  personnel  administration  areas 
can  be  addressed  with  this  system  and  what 
modifications  will  be  required? 
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E.  SCOPE  AND  LIMITATIONS 

This  thesis  will  provide  background  information  on  the 
Department  of  Defense/Navy  (DOD/DON)  manpower  development 
process  and  a  description  of  the  documents  used  at  the 
activity  level  for  manpower  analysis.  Functional  and  Data 
requirements  for  activity  level  manpower  analysis  will  be 
identified,  and  a  logical  database  design  presented. 

Examples  of  outputs  and  reports  will  also  be  included. 

The  scope  of  this  thesis  is  limited  to  system  analysis 
and  design.  It  does  not  include  implementation  of  the 
proposed  design  or  building  of  a  prototype. 

F .  METHODOLOGY 

Object  oriented  database  analysis  and  design  methodology 
will  be  used  to  define  functional  and  data  requirements  and 
to  present  a  logical  database  design.  This  methodology  will 
be  described  in  Chapter  III,  User  Requirements. 

Functional  and  data  requirements  for  this  system  will  be 
based  on  the  author's  professional  experience  as  a  U.S.  Navy 
Manpower  Analyst  for  six  and  one-half  years  at  the  Echelon 
three,  four,  and  five  levels:  Commander  Oceanographic 
System  Atlantic  (primary  billet  -  1983-85) ;  Commander 
Helicopter  Tactical  Wing  One  (1985-88);  and  Naval  Air 
Station,  Agana ,  Guam  (1980-81),  respectively. 
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G.  ORGANIZATION  OF  THESIS 


This  thesis  is  organized  as  follows: 

Chapter  II,  entitled  ’’Manpower  Management  in  the  Navy", 
reviews  the  Department  of  Defense/Navy  (DOD/DON)  level 
processes  for  determining  activity  manpower  requirements. 
Views  of  manpower  from  the  three  upper  levels  of  management 
at  an  activity  will  be  presented  and  the  documents  required 
for  activity  level  manpower  analysis  will  be  reviewed. 
Reports  generated  by  the  manpower  analysis  process  will  be 
presented  within  the  context  of  management  views  of 
manpower . 

Chapter  III,  entitled  "User  Requirements",  reviews  the 
methodology  used  to  define  data  and  functional  requirements, 
develops  the  objects  to  be  stored  in  the  database,  and 
determines  the  processes  that  create,  modify  and  display 
these  objects.  Using  data  from  several  sources,  a  database 
is  defined  which  contains  information  on  personnel  assigned 
to  an  activity  and  the  activity's  billet  structure.  The 
database  system,  once  designed,  will  process  the  information 
from  the  database  to  produce  a  series  of  predefined  reports 
or  respond  to  ad  hoc  queries  on  the  database. 

Chapter  IV,  "Design",  presents  the  logical  database 
design  using  Object  Oriented  methodology  and  the  Relational 
Database  Model.  Using  this  methodology,  objects  identified 
in  the  previous  chapter  are  transformed  into  a  relational 
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diagram.  Data  flows  and  report  outputs  of  the  system  are 
also  specified  in,  Appendices  C  and  D,  respectively. 

Chapter  V,  entitled  "Summary  and  Conclusions",  provides 
a  brief  review  of  the  previous  four  chapters  and  presents 
suggestions  for  alternative  functionality  of  the  system. 

Appendices  A  through  C  provide  Object  Diagrams,  Object 
Specifications  and  Object  Oriented  Data  Flow  Diagrams, 
respectively,  developed  during  the  Requirements  Analysis 
phase.  Appendix  D  provides  Sample  Forms/Data  Input/Display 
Screens  and  Reports  designed  for  data  input  and  modification 
and  data  output,  respectively.  Appendices  E  and  F  were 
developed  during  the  design  phase  of  this  thesis  and  provide 
a  graphic.  Appendix  F,  and  literal  description  of 
relationships  between  the  Objects  presented  in  Appendix  A. 
Appendix  G  defines  system  requirements  for  Update,  Display, 
and  Control  Mechanisms.  Appendix  H  illustrates  the  system 
Menu  Hierarchy  and  provides  sample  menus  for  the  system. 
Appendix  I  provides  Pseudo  Code  for  the  Menu  Hierarchy  as 
well  as  for  the  reports  generation  procedures. 
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II.  MANPOWER  ANALYSIS 


Chapter  I  provided  a  brief  background  on  the  manpower 
analysis  process  and  the  importance  of  that  process.  This 
chapter  reviews  the  Department  of  Defense/Navy  (DOD/DON) 
level  processes  for  determining  activity  manpower 
requirements.  Views  of  manpower  from  the  three  upper  levels 
of  management  at  an  activity  are  presented,  and  the 
documents  required  for  activity  level  manpower  analysis  are 
reviewed.  Reports  generated  by  the  manpower  analysis 
process  are  presented  within  the  context  of  management  views 
of  manpower. 

A.  DEPARTMENT  OF  DEFENSE/NAVY  (DOD/DON)  MANPOWER 
PROGRAMMING 

Manpower  requirements  for  the  DOD/DON  are  determined,  in 
part,  by  the  authorized  configuration  of  weapons  systems, 
force  structure,  warfare  tasking,  and  support  thereof.  A 
Naval  activity's  billet  structure  is,  therefore,  directly 
linked  to  the  Department  of  Defense's  (DOD)  Planning, 
Programming,  and  Budgeting  System  (PPBS) .  Initiated 
annually,  the  PPBS  operates  on  an  eighteen  month  cycle. 
Events  in  this  cycle  lead  directly  to  the  development  and 
authorization  of  Navy  manpower. 
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1.  DOD  Planning,  Programming,  and  Budgeting  System 
(PPB8) 

The  President,  National  Security  Council,  Joint 
Chiefs  of  Staff  (JCS) ,  and  DOD  evaluate  the  threat  to 
national  security  based  on  intelligence  collected.  The  JCS 
then  develop  a  strategy  to  meet  these  threats  to  national 
security  and  promulgate  it  in  the  Joint  Strategic  Planning 
Document  (JSPD)  to  the  Secretary  of  Defense  (SECDEF) .  The 
SECDEF  then  issues  guidance  to  the  Military  Departments  in 
the  areas  of  Fiscal  Policy,  Material  Support  Planning,  and 
Preparation  of  the  Program  Objective  Memorandum  (POM) .  The 
military  departments  submit  POM  to  the  SECDEF  in  response  to 
this  guidance.  The  POM  submissions  contain  recommendations 
as  to  the  forces  and  resources  required  to  support  national 
defense  objectives  as  well  as  the  rationale  for  these 
recommendations  and  risk  assessments.  Once  force 
requirements  have  been  determined,  manpower  requirements 
necessary  to  support  the  forces  are  established. 

[Ref .  1 : Chap.  3 ] . 

2 .  DOD  POM 

POM  submissions  are  fiscally  constrained  and 
developed  by  fiscal  year.  Planned  forces  are  programmed  for 
eight  fiscal  years,  and  the  manpower  to  support  the  forces 
is  programmed  for  six  fiscal  years.  "Upon  receipt  of  the 
POM  submissions  from  each  Military  Department,  the  SECDEF 
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requests  the  JCS  to  prepare  the  Joint  Program  Assessment 
Memorandum  (JPAM)".  [Ref.  l:Chap.  3],  After  analyzing  the 
POM  submissions  and  the  JPAM,  the  SECDEF  issues  Program 
Decision  Memorandum  (PDMs)  which  include  intended 
adjustments  to  the  POM  submissions.  The  Military 
Departments  submit  budget  estimates  based  on  Program 
Decision  Memorandum  to  the  SECDEF.  After  evaluating  of 
these  budget  estimates,  by  SECDEF  and  Office  of  Management 
and  Budget  (0MB).  SECDEF  develops  "...  Decision  Package 
Sets  and  submits  the  DOD  budget  as  part  of  the  President's 
budget  to  Congress".^  [Ref.  l:Chap.  3].  Figure  2-1 
illustrates  this  PPBS  process.  Figure  2-2  illustrates  the 
entire  Manpower  Requirements  Determination  Process. 

B.  DOM  MANPOWER  REQUIREMENTS  DETERMINATION 
1.  Operating  Forces 

In  the  Department  of  the  Navy  (DON) ,  determining  the 
manpower  requirements  for  operating  forces,  i.e.  ships, 
submarines,  and  aviation  squadrons,  is  a  complex  process 
based  on  established  engineering  standards  and  other 
methodologies.  Beginning  with  an  operating  unit's  Required 
Operational  Capability  (ROC)  or  mission  statement,  and  the 
Projected  Operational  Environment  (POE)  or  specific 
operating  scenario,  then  determining  operating  and 

’Budget  decisions  are  contained  in  Program  Budget  Decision 
(PBDs)  and  Defense  Management  Review  Decisions  (DMRDs) . 
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maintenance  requirements  for  equipment  installed  at  that 
unit  to  support  the  ROC/POE,  the  manpower  analyst  can  apply 
a  set  of  algorithms  and  engineering  standards  to  determine 
the  billet/manpower  quality  and  quantity  mix  required  for 
the  unit  to  be  fully  mission  capable.  The  wartime  or  full 
mission  requirement  billet  structure  for  each  unit  in  the 
operating  force  is  then  published  in  the  unit's  Manpower 
Document . 

Each  Ship  Manpower  Document  (SMD)  and  Squadron 
Manpower  Document  (SQMD)  identifies  the  "minimum  wartime 
qualitative  and  quantitative  manpower  requirements  to 
support  accomplishment  of  all  assigned  missions  and  Required 
Operational  Capabilities  in  the  Projected  Operational 
Environment  ROC/ POE".  [Ref.  l:Chap.  2].  These  documents 

delineate,  by  departmental  and  divisional  breakdown,  the 
required  officer  and  enlisted  billet  structure  for  an 
activity.  This  structure  is  defined  in  terms  of  officer 
warfare  designations  and  grade;  enlisted  ratings, 
subspecialties  or  NECs,  and  paygrades;  and  the  quantity 
required  of  each. 

2.  Shore  Activities 

The  mission  of  Navy  shore  activities  is  to  provide 
support  to  the  operating  forces.  This  support  includes,  but 
is  not  limited  to,  mission  areas  such  as  supply,  fire 
fighting,  intelligence,  aircraft/ship  rework,  and  staff 
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administrative  activities.  These  support  functions  are  not 
directly  related  to  the  operations  of  war-fighting  hardware; 
therefore,  the  manpower  effort  required  to  provide  these 
services  cannot  be  measured  by  hardware  engineering 
standards . 

The  current  method  being  used  by  DON  to  determine 
shore  facility  billet  structure  is  the  Efficiency  Review 
(ER)  process.  Completion  of  ERs  on  all  Naval  shore 
activities  is  scheduled  for  FY  1994.  From  this  process  the 
Most  Efficient  Organization  (MEO)  which  "defines  the  minimum 
quality  and  quantity  of  manpower  required  to  produce  the 
output (s)  established  in  the  activities  Performance  Work 
Statement  (PWS)"  will  be  derived.  [Ref.  l:Chap.  3].  "The 
Objective  is  to  develop  a  manpower  requirements  baseline  to 
use  as  a  basis  for  programming  all  shore  manpower 
requirements".  [Ref.  l:Chap.  2].  The  end  result  of  this 
entire  process  will  be  a  Shore  Manpower  Document  (SHMD) , 
similar  in  structure  to  the  SMD  and  SQMD,  for  each  U.S.  Navy 
shore  activity. 

3.  Manpower  Authorization  (MPA)  (OPNAV  1000/2) 

The  next  step  in  the  manpower  process  is  to 
deteimine  p^^acetime  mission  requirements  for  all  Naval 
activities,  operating  forces  and  shore  activities.  From 
these  requirements,  the  peacetime  force  structure  (ships, 
submarines,  and  aircraft,  etc.)  and  shore  facilities 
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structure  are  determined  within  budgetary  constraints  set  by 
Congress.  The  Manpower  Authorization  (MPA)  (OPNAV  1000/2) 
outlines  Chief  of  Naval  Operations  (CNO)  approved  and  funded 
billets  for  each  Naval  activity  based  on  budgetary 
constraints,  warfare  priorities,  and  manning  policies. 
Currently  the  DON'S  goal  is  to  have  billet  authorization 
(BA)  levels  at  91.5  percent  of  requirements  for  operating 
forces  (deployable,  military  personnel  only)  and  90  percent 
or  less  of  requirements  for  shore  facilities  (combined 
military,  civilian,  and  civilian  contract  personnel) . 

[Ref s .  2  and  3 ] . 

4.  Personnel  Levels 

The  actual  number  of  personnel  assigned  for  duty  to 
a  Naval  activity  at  any  given  time  is  determined  by  a 
complex  set  of  factors,  the  explanation  of  which  is  beyond 
the  scope  of  this  thesis.  It  is  sufficient  to  understand 
that  the  quality  and  quantity  mix  of  personnel  assigned  to 
an  activity  ranges  from  70  to  88  percent  of  BA,  with  each 
activity  receiving  its  "fair  share"  of  Navy  personnel  assets 
as  determined  by  the  Navy  Manning  Plan  (NMP)  for  Enlisted 
personnel  and  the  Officer  Navy  Manning  Plan  (ONMP) . 

[Refs.  2  and  3].  Because  there  is  a  difference  between  BA 
levels  and  actual  personnel  on  board,  it  is  vital  that 
managers  recognize  this  fact  and  manage  these  limited  assets 
to  ensure  mission  accomplishment  and  combat  readiness. 
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C.  PRESENT  SYSTEM  -  ACTIVITY  LEVEL  MANPOWER  ANALYSIS 
1.  Personnel  and  Billet  Data  Sources 

The  location  of  Naval  personnel,  based  on  official 
Permanent  Change  of  Station  (PCS)  orders  is  maintained  in 
database  systems  at  the  Consolidated  Data  Center  (CDC)  in 
Cleveland,  Ohio.  These  systems  are  the  Naval  Enlisted 
System  (NES)  and  the  Officer  Personnel  Information  System 
(OPINS) ,  commonly  referred  to  as  the  Enlisted  Master  File 
and  the  Officer  Master  File.  However,  direct  access  to 
these  databases  is  restricted  to  the  upper  echelons  of  the 
DON. 

Lower  echelon  activities  such  as  ships,  aviation 
squadrons  and  Naval  bases  do  not  have  direct  access  to  these 
database  systems.  Therefore,  in  order  to  fully  analyze 
their  manpower,  data  from  several  sources,  internal  and 
external  to  the  command,  are  required.  Internal  documents 
include  the  personnel  service  records  and  personnel  rosters. 
Externally  generated  documents  used  in  activity  level 
manpower  analysis  include  the  following: 

a.  Manpower  Authorization  (MPA)  (OPNAV  1000/2) 

The  Manpower  Authorization  (MPA) ,  produced  by  the 
Navy  Manpower  Data  Accounting  System  (NMDAS) ,  is  used  to 
fully  identify  the  peacetime  and  mobilization  billet 
structure  of  an  activity.  Two  MPAs  are  published  for  each 
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command,  one  for  officer  billets  and  one  for  enlisted 
billets.  Both  are  divided  by  department  and  division,  and 
the  billets  assigned  to  each  are  delineated. 

Billets  are  identified  by  Billet  Sequence  Code 
(BSC)  and  Billet  Title.  Each  billet  is  then  assigned 
specific  enlisted  rating  and  Primary  and  Secondary  Naval 
Enlisted  Classification  codes  (PNEC/SNEC)  requirements  or 
officer  warfare  designator,  grade,  and  subspecialty  codes, 
if  applicable.  The  authorized  peacetime  quantity  for  each 
billet  is  specified  for  the  current  Fiscal  Year  (FY)  and 
subsequent  five  FYs. 

MPAs  for  an  activity  must  be  reviewed  when  the 
activity  receives  a  new  edition  in  order  to  identify  or 
verify  changes,  if  any,  which  have  occurred  to  the 
authorized  peacetime  or  wartime  billet  structure.  Changes 
to  an  activity's  billet  structure  are  also  identified 
through  correspondence  from  the  appropriate  resource 
sponsor.  For  example,  changes  would  include  notification 
that  an  NEC  is  to  be  to  be  applied  to  specific  ratings  or 
notification  granting  authority  to  establish  a  new 
department  within  an  activity  and  providing  its  associated 
billet  structure. 

b.  Enlisted  Distribution  Verification  Report  (EDVR) 

The  Enlisted  Distribution  Verification  Report 
(EDVR) ,  produced  by  NES,  is  received  monthly  by  each  Naval 
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activity  with  enlisted  personnel  assigned.  This  document 
lists  assigned  enlisted  personnel  alphabetically  by  last 
name  and  alphabetically  by  rate.  Information  provided  on 
each  person  includes  his  actual  rating  and  assigned  rating 
(rating  detailed  against) ,  PNEC/SNEC  held  and  distributed 
against,  Projected  Rotation  Date  (PRD) ,  End  of  Active 
Obligated  Service  Date  (EAOS) ,  Active  Duty  Service  Date 
(ADSD) ,  and  Social  Security  Number  (SSN) .  Prospective 
personnel  gains  and  losses  are  also  identified  by  name  and 
rate  and  estimated  date  of  arrival  or  departure, 
respectively.  The  activity's  billet  authorization  level  and 
current  month  and  nine  month  projected  onboard  manning 
levels  are  also  provided  as  well  as  the  NMP  allotment  for 
each  rating. 

c.  Officer  Distribution  Control  Report  (ODCR) 

The  Officer  Distribution  Control  Report  (ODCR), 
produced  by  OPINS,  also  published  monthly,  lists  officers 
assigned  to  a  command  by  BSC  and  Billet  Title.  Grade, 
designator,  subspecialty,  date  of  rank,  PRD,  sex,  and  SSN 
are  also  provided. 

Information  on  officer  and  enlisted  personnel  is 
also  gleaned  from  Permanent  Change  of  Station  (PCS)  orders 
and  an  individual's  Personnel  Record. 
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d.  Detailing  of  Personnel 

Although  officers  are  officially  detailed  to  a 
specific  billet  within  their  activity,  they  may  actually  be 
assigned  to  a  different  billet  by  their  Executive  or 
Commanding  Officer  once  they  report  for  duty.  Enlisted 
personnel  are  generally  not  detailed  to  a  specific  billet, 
but  to  an  opening  for  a  specific  rating  and  paygrade  or  NEC 
requirement.  There  are  exceptions  to  this  system  for 
enlisted  personnel  such  as  directed  manning  for  Command 
Master  Chief,  Command  Career  Counselor  billets  and  other 
high  interest  or  controlled  billets.  When  an  enlisted 
member  reports  to  an  activity  he/she  is  assigned  to  a 
department  or  division.  The  officer  in  charge  of  his/her 
work  unit  then  assigns  specific  duties  to  be  performed  by 
the  individual. 

2 .  Activity  Management  Levels 

There  are  three  levels  of  management  in  an  activity 
that  are  concerned  with  billet/personnel  management: 
a.  Executive  Level 

This  level  consists  of  the  Commanding  Officer 
(CO) ,  Executive  Officer  (XO) ,  and  selected  Executive 
Assistants  such  as  the  Command  Career  Counselor  (CCC)  and 
Command  Master  Chief  (CMC) . 
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b.  Department  Heads 

Department  Heads  are  officers  who  are  assigned 
responsibility  for  a  major  mission  component  of  an  activity 
such  as  Operations,  Weapons,  or  Administration.  Department 
Heads  are  assigned  responsibility  for  managing  several 
subordinate  officers  and  numerous  enlisted  personnel  who  are 
grouped  into  functional  subareas,  called  divisions,  within  a 
department . 

c.  Division  Officers 

Officers  at  this  level  of  management  are  assigned 
responsibility  for  a  division  within  a  department.  A 
division  includes  numerous  enlisted  personnel  of  varying 
rates . 

3.  Management  Views  of  Manpower 

The  Executive  Level,  specifically  the  CO  and  XO, 
view  enlisted  manpower  differently  from  the  other  two  levels 
of  management  discussed  above.  The  CO  and  XO  generally  view 
enlisted  manpower  in  terms  of  the  quantity  of  personnel 
onboard  in  each  department  or  division;  percentages  of 
personnel  onboard  versus  Billets  Authorized  (BA) ;  a  specific 
comparison  of  the  number  of  billets  and  personnel  assigned 
per  department  and  division;  and  projected  shortfalls  and 
end  strength. 

Officer  manpower,  on  the  other  hand,  is  viewed  from 
this  level  in  terms  of  an  individual  assigned  against  a 
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specific  billet,  as  well  as  overall  current  and  projected 
officer  manning  levels.  The  Executive  Officer  of  a  command 
is  responsible  for  the  billet  assignment  of  officers.  The 
other  members  of  the  Executive  Level,  the  CCC  and  CMC,  deal 
primarily  with  career  development,  and  morale  and  welfare  of 
enlisted  personnel,  respectively. 

Department  Heads  and  Division  Officers  view  enlisted 
manpower  in  terms  of  BA  versus  personnel  assigned  ratios  as 
well  as  specific  enlisted  billet  assignments.  Department 
Heads  and  Division  Officers  must  actively  project  future 
manning  levels  against  specific  billets  to  ensure  combat 
readiness  and  miss’  .  accomplishment. 

4.  Manpower  l.Aialysis  Process 

As  F'-iitioned  previously,  manpower  analysis  is  the 
process  ’-y  which  an  activity's  personnel  assets  are  matched 
to  or  Balanced  against  its  authorized  billets.  Often  the 
manpower  analysis  and  reports  generation  process  at  an 
activity  is  a  manual  process  performed  by  an  officer 
assigned  as  the  Command  Manpower  Analyst  or  by  an  individual 
Department  Head  or  Division  Officer  for  their  respective 
department,  division,  or  work  centers.  These  reports  can 
take  anywhere  from  a  few  minutes  to  several  hours  to  produce 
manually,  depending  on  the  data  required  and  the  accuracy, 
currency,  and  availability  of  the  data. 
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Because  of  the  time  lag  between  NES  and  OPINS 
database  updates,  publishing  dates,  and  receipt  of  the  EDVR 
and  ODCR  by  an  activity,  there  are  frequently  discrepancies 
between  data  in  these  documents  data  in  and  the  individual's 
personnel  record.  The  same  is  also  true  for  NMDAS  and  the 
MPA.  Information  gleaned  from  the  MPA,  EDVR,  ODCR,  PCS 
orders.  Personnel  Records,  billet  assignments,  and 
personnel/billet  correspondence  from  higher  authority  is 
used  to  manage  billets  and  manpower  within  an  activity. 
Figure  2-3  illustrates  the  flows  of  data  through  the 
manpower  analysis  system. 

a.  System  Data  Flows 

Figure  2-3  illustrates  a  general  view  of  activity 
level  manpower  analysis.  Sources  and  sinks  as  well  as 
senders  and  receivers  of  data  within  the  system  are 
represented  by  boxes.  The  term  'Higher  Authority'  refers  to 
an  activity  at  an  echelon  higher  than  the  activity 
performing  manpower  analysis.  These  Higher  Authorities  are 
responsible  for  making  decisions  on  billet  structure  and 
assignment  of  personnel  for  subordinate  activities. 

Higher  Authority  activities,  in  the  context  of 
this  thesis,  are  as  follows; 

Chief  of  Naval  Operations  (OP-12) , 
responsible  office  for  MPA  changes  as 
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(1)  Billet  Data  (MPA  &  Notification  Letter)  (9)  Department  Manning  Report 

(2)  Personnel  Data  (ODCR.EDVR)  (10)  Division  Manning  Report 

(3)  Personnel  Data  (Personnel  Record)  (1 1)  Officer  Billet  Assignment 

(4)  Department  Status  Report  (12)  Officer  Manning  Report 

(5)  Division  Status  Report  (13)  Officer  Status  Report 

(6)  Designator/Ratng  Status  Report  (14)  Personnel  Gains/Losses  Report 

(7)  Enlisted  Billet  Assignment  (15)  Officer  and  Enlisted  PCS  Orders 

(8)  Grade/Paygrade  Status  Report 


Figure  2-3:  Manpower  Analysis  Process  Data  Flow  Diagram 
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directed  by  resource  sponsors  and  manpower 
claimants . 

-  Resource  Sponsors,  offices  within  OPNAV 
responsible  for  ensuring  resources  are 
available  in  the  various  warfare  communities 
for  mission  accomplishment. 

EPMAC,  performs  placement  for  all  active 
and  Training  and  Administration  of  Reserves 
(TAR)  enlisted  duty  personnel;  detailing  of 
non-designated  airmen,  seamen,  and  firemen; 
NEC  management;  production  and  distribution 
of  EDVR  using  NES. 

Naval  Military  Personnel  Command  (NMPC) , 
responsible  for  detailing  and  placement  of 
officers,  and  detailing  of  all  other  enlisted 
personnel . 

Data  flowing  from  Higher  Authority  will  include 
billet  information  and  personnel  assignment  information. 

Data  flowing  from  the  Commanding 
Officer/Executive  Officer  (CO/XO)  source  to  the  system  will 
normally  include  only  officer  billet  assignments. 

Information  flowing  to  the  CO/XO  sink  will  be  the  various 
manpower  analysis  reports  produced  by  the  system  and 
required  by  this  level  of  management.  These  reports  will  be 
discussed  in  Section  5  of  this  chapter. 
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Division  Officers  and  Department  Heads  will 
provide  data  to  the  system  concerning  enlisted  billet 
assignments.  As  a  data  sink,  tnis  level  of  management  will 
use  reports  generated  by  the  system. 

Data  from  the  Personnel  Record  will  be  used  by 
the  system  to  update  the  database,  but  no  information  or 
data  will  be  sent  from  the  system  to  the  personnel  record. 
b.  Major  System  Components  Data  Flovs 

Figure  2-4  illustrates  the  flow  of  data  into  and 
out  of  the  two  major  components  of  a  manpower  analysis 
system.  These  major  components  are  the  processes  for 
managing  billet  and  personnel  data  and  for  creating  reports. 

The  data  management  process  encompasses 
mechanisms  for  adding  new  data,  modifying  existing  data,  and 
deleting  data  which  is  no  longer  required.  The  primary 
purpose  of  any  database  is  to  maintain  data  for  use  by 
decision  makers.  The  manpower  analysis  process  ultimately 
produces  reports  for  the  users  which  present  various 
consolidated  views  of  an  activity's  manpower.  Additionally, 
the  database  should  be  capable  of  providing  simple  lists  of 
groups  of  data  as  well  as  responses  to  ad  hoc  queries. 

5.  Reports 

Reports  generated  by  the  manpower  analysis  process 
are  reflections  of  the  management  views  of  manpower. 

Reports  on  officer  manpower  would  include  a  break-down  of 
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Manpower 

Database 


LEGEND 

(1)  Billet  Data  (MPA)  and  Notification  Letter 

(2)  Personnel  Data  (ODCR,  EDVR) 

(3)  Personnel  Data  (Personnel  Record) 

(4)  Officer  Billet  Assignment 

(5)  Enlisted  Billet  Assignment 

(6)  Officer  Billet  Data 

(7)  Enlisted  Billet  Data 

(8)  Officer  Record 

(9)  Enlisted  Record 

(10)  Officer  and  Enlisted  PCS  Orders 


(11)  Department  Billet  Structure 

(12)  Division  Billet  Structure 

(13)  Grade/Paygrade  Status  Report 

(14)  Designator/Rating  Status  Report 

(15)  Department  Status  Report 

(16)  Division  Status  Report 

(17)  Officer  Status  Report 

(18)  Officer  Manning  Report 

(19)  Department  Manning  Report 

(20)  Division  Manning  Report 

(21)  Personnel  Gain^Losses  Report 


Figure  2-4:  SuLprocesses  Data  Flow  Diagram 
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personnel  by  paygrade  and/or  rank,  billet  summary  by 
department/division,  and  a  designator  summary.  Enlisted 
reports  would  include  essentially  the  same  break-down 
profiles.  Both  officer  and  enlisted  reports  provide 
strictly  numeric  views  of  the  information  in  the  database  as 
well  as  views  of  specific  billet/personnel  assignments. 
Appendix  D  provides  samples  of  reports  illustrating  views  of 
the  data  normally  required  by  activity  level  management. 
(These  reports  will  be  discussed  in  detail  in  Chapter  III) . 
Not  all  levels  of  management  need  to  see  the  same  levels  of 
detail  in  a  report;  therefore,  the  manpower  data  must  be 
combined,  analyzed,  and  presented  in  different  formats. 

D.  SUMMARY 

This  chapter  provided  background  information  on  the 
DOD/DON  level  manpower  requirements  determination  processes. 
At  the  DON  level,  several  documents  are  generated  which,  if 
used  by  an  activity,  provide  all  of  the  data  necessary  for 
effective  manpower  analysis.  The  manpower  analysis  process 
was  summarized  and  an  overview  of  reports  generated  by  the 
process  was  presented. 

Chapter  III  reviews  the  methodology  used  to  define  data 
and  functional  requirements,  develops  the  objects  to  be  stored 
in  the  database,  and  determine  the  processes  that  create, 
modify  and  display  these  objects. 
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III.  SYSTEM  REQUIREMENTS 


This  chapter  defines  the  data  and  functional 
requirements  for  an  automated  manpower  analysis  system. 

Using  data  from  several  sources,  a  database  is  created  which 
contains  information  on  personnel  assigned  to  an  activity 
and  the  activity's  billet  structure.  The  database  system 
will  then  process  the  information  from  the  database  to 
produce  a  series  of  predefined  reports  or  to  respond  to  ad 
hoc  queries  on  the  database. 

A.  METHODOLOGY 

Object  oriented  methodology  is  used  to  define  data  and 
functional  requirements  for  the  database  system.  Using  this 
methodology,  the  entities  in  the  user's  work  environment  are 
represented  as  objects  to  be  stored  in  the  database.  An 
entity  is  any  item  in  the  user's  work  environment  about 
which  information  is  required  to  be  stored.  For  example,  an 
Officer  would  be  an  entity  in  a  Naval  activity's  personnel 
management  environment.  The  characteristics  of  each  object 
are  defined  in  terms  of  the  data  elements  to  be  stored. 

Functional  requirements  for  the  database  system  are 
defined  through  the  use  of  Data  Flow  Diagrams  (DFDs) .  DFDs 
present  graphically  how  each  object  in  the  user's  work 
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environment  is  created,  modified,  deleted,  and  displayed. 
DFDs  also  illustrate  who  is  authorized  to  do  what  to  each 
object  and,  within  the  user's  work  environment,  to  whom 
information  from  the  system  is  given. 

1.  DATA  REQUIREMENTS  DEFINITION 

Using  object  oriented  methodology,  the  systems 
analyst  must  first  identify  those  'objects'  in  the  user's 
environment  that  must  be  maintained  and  define  their 
structure.  An  object  is  defined  as  a  "...  named  collection 
of  properties  that  sufficiently  describes  an  entity  in  the 
user's  work  environment."  A  property  is  a  "... 
characteristic  of  an  entity  that  is  important  to  one  or  more 
users  of  the  database  application  ...",  such  as  a  person's 
name  or  rank.’  "An  entity  is  something  the  user  perceives 
to  be  an  independent  unit...",  such  as  a  department  or  an 
officer.  [Ref.  4: Chap  4]. 

a.  Object  Definitions 

To  define  the  objects  in  the  user's  environment 
for  the  AMA/PMS,  both  system  outputs  and  entities  in  the 
user's  work  environment  were  examined  to  fully  identify  the 
characteristics  or  properties  to  be  maintained  by  the 
system.  These  objects  represent  a  consolidated  view  of  the 
entities  and  their  characteristics  in  the  user's 


’a  property  of  an  object  may  also  be  another  object.  In  this 
case  it  is  called  an  object  property. 
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environment,  a  Naval  activity.  All  Naval  activities  are 
divided  into  departments  which  are  then  divided  into 
divisions.  Some  divisions  are  then  further  divided  into 
workcenters  (for  the  purpose  of  this  thesis,  an  activity 
will  be  subdivided  only  to  the  division  level) .  Personnel 
are  assigned  to  work  within  specific  departments  and 
divisions  at  an  activity.  The  manpower  of  a  Naval  activity 
is  viewed  in  terms  of  billet  structure  and  personnel 
onboard. 


From  the  object  oriented  view  of  activity 
manpower,  six  entities  are  identified  in  the  user's  work 
environment  of  Manpower/Personnel  Management  about  which 
data  must  be  maintained.  For  the  AMA/PMS  these  entities  are 
defined  as  the  objects;  DEPARTMENT,  DIVISION,  OBILLET 
(officer  billet),  EBILLET  (enlisted  billet),  OFFICER,  and 
ENLISTED.  Appendix  A  graphically  presents  the  properties  of 
each  object. 

b.  Object  Specifications 

Once  the  objects  have  been  defined,  object 

specifications  are  developed. 

"Object  specifications  consist  of  two  parts:  object 
definitions  and  domain  definitions.  An  object 
definition  lists  all  the  properties  of  an  object  and 
indicates  the  domain  from  which  values  for  each  property 
may  be  drawn.  Domain  definitions  specify  formats, 
lengths  and  special  restrictions  on  the  values  of  each 
domain".  [Ref.  4: Chap  4]. 
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Object  Definitions  and  Domain  Definitions  are  presented  in 
Appendix  B. 

c.  Object  Descriptions 

(1)  Department  and  Division  Objects.  The 
billets^*  within  an  activity  are  divided  into  Departments  and 
then  subdivided  into  divisions.  For  example,  the  Aviation 
Maintenance  Department  would  include  divisions  called 
Scheduling,  Avionics  and  Electronics.  The  DEPARTMENT  object 
is  identified  by  Dname.  This  object  contains  the  object 
properties  of  DIVISION,  OBILLET,  EBILLET,  OFFICER,  and 
ENLISTED,  all  of  which  may  be  multivalued. 

The  DIVISION  object  is  identified  by 
DivName.  This  object  also  contains  the  object  properties  of 
OBILLET,  EBILLET,  OFFICER,  and  ENLISTED,  as  well  as  the  non¬ 
object  property  Dname.  Again,  each  of  these  object 
properties  may  be  multivalued. 

(2)  Billet  Objects.  Billets  are  categorized 
as  requiring  either  an  officer  or  an  enlisted  person  to  be 
assigned.  The  objects  defined  to  represent  these  entities 
are  OBILLET  and  EBILLET.  Billet  data  is  obtained  from  the 
Manpower  Authorization  (MPA)  OPNAV  1000/2  or  via  official 
correspondence  from  a  Resource  Sponsor  which  identifies 
changes  to  an  activity's  billet  structure,  hereafter 


*The  billet  structure  of  an  activity  defines  the  job 
organization.  Therefore,  a  billet  is  a  specific  element  of  the 
work  breakdown  structure  of  the  activity. 
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referred  to  as  a  Notification  Letter.  Billet  data  is 


entered  into  the  system  to  create,  modify,  or  delete  a 
unique  instance  of  OBILLET  or  EBILLET  objects.  These 
instances  of  OBILLET  and  EBILLET  objects  are  then  grouped  to 
create  instances  of  DEPARTMENT  and  DIVISION  objects. 

The  OBILLET  and  EBILLET  objects  contain 
several  identical  properties.  Both  objects  are  identified 
by  a  Billet  Sequence  Code  (BSC)  which  is  unique  to  each 
instance  of  that  object.  Each  contains  properties  called 
Billet  Title;  Billet  Authorization  (BA) ,  the  number  of 
billets  authorized  for  that  BSC;  Department  Name  (DName) ; 
and  Division  Name  (DivName) .  All  billets  are  assigned  to  a 
department,  but  not  all  billets  are  assigned  to  a  specific 
division.  Several  billets  may  be  assigned  to  an  area  within 
the  department  commonly  referred  to  as  Departmental 
Administration. 

The  OBILLET  object  contains  properties  for 
Grade  and  Designator  (indicating  the  rank  and  warfare 
designator,  respectively),  ideally  required  for  that  billet. 
Additionally,  one  or  more  instances  of  OFFICER  object  may  be 
associated  with  a  specific  instance  of  the  OBILLET  object.^ 

Properties  within  the  EBILLET  object  are 
Rating,  an  alphanumeric  acronym  for  an  enlisted  technical 

^ore  than  one  officer  may  be  temporarily  assigned  to  a  single 
instance  of  OBILLET  during  periods  of  personnel  turnover  and 
reassignment . 
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rate  and  paygrade;  paygrade;  Primary  or  Secondary  Naval 
Enlisted  Classification  (PNEC/SNEC)  code,  a  numeric  code 
specifying  a  technical  subspecialty  within  a  specific 
rating;  BA;  Dname;  and  DivName.  One  or  more  instances  of 
ENLISTED  object  may  be  associated  with  a  single  instance  of 
EBILLET  object.® 

(3)  Personnel  Objects.  Members  of  the  Armed 
Forces  are  either  Commissioned  Officers  or  Enlisted 
Personnel.  Personnel  data  gleaned  from  the  Officer 
Di^-tribution  Control  Report  (ODCR)  ,  the  Enlisted 
Distribution  Verification  Report  (EDVR) ,  Permanent  Change  of 
Station  (PCS)  orders,  Personnel  Service  Records,  and 
personnel  data  input  or  change  forms  (as  created  and  used  by 
each  activity)  is  entered  into  the  system  to  create,  modify, 
and  delete  unique  instances  of  OFFICER  and  ENLISTED  objects. 

Each  instance  of  the  OFFICER  object  is 
identified  by  the  individual's  SSN.  This  object  contains 
the  properties  of  Name,  Grade,  Projected  Rotation  Date 
(PRD) ,  and  Date  of  Rank,  as  well  as  the  object  properties  of 
DEPARTMENT  and  DIVISION.  The  property  Collateral  Duties  may 
be  multivalued  and  describes  the  non-billet  duties  assigned 
to  an  officer  such  as  Urinanalysis  Officer  or  Navy  Relief 
Coordinator.  The  object  properties,  OFFICER,  DEPARTMENT, 


®More  than  one  Enlisted  person  may  be  temporarily  assigned  to 
an  instance  of  EBILLIT  during  periods  of  turnover  and  reassignment. 
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and  DIVISION  are  single  valued,  however,  the  object  property 
of  OBILLET  may  be  multivalued  as  an  officer  may  be  assigned 
to  more  than  one  billet. 

The  ENLISTED  object  is  identified  by  SSN 
for  each  instance  in  the  database.  Other  properties  in  this 
object  include  Name,  Rating,  Paygrade,  Rate,  PNEC,  SNEC, 

PRD,  End  of  Active  Obligated  Service  (EAOS)  date.  Date  of 
Rank,  and  Time  in  Service.  As  Enlisted  personnel  are 
initially  assigned  to  a  department  and  division  then  to  a 
billet,  these  object  properties  are  included.  An  enlisted 
member  may  only  be  assigned  to  a  single  department  or 
division  at  a  time  but  may  be  assigned  to  more  than  one 
billet.  The  property  Collateral  Duties  is  multivalued. 

These  non-billet  duties  may  include  assignments  such  as 
Watch  Section  Leader  or  Training  Petty  Officer, 
d.  Management  Views  of  Objects 

The  Executive  level  of  a  command  views  the 
activity  as  a  collection  of  DEPARTMENT  objects,  each  of 
which  is  divided  into  a  collection  of  DIVISION  objects. 

Each  of  these  objects  is  viewed  as  containing  several 
instances  of  OBILLET  and  EBILLET  objects.  From  this  level, 
OBILLETs  are  viewed  as  containing  instances  of  OFFICER 
object.  Enlisted  personnel  are  viewed  as  belonging  to  a 
specific  instance  of  DEPARTMENT  or  DIVISION  object. 
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Lower  management  levels  of  a  command,  i.e.. 
Department  Heads  and  Division  Officers,  view  the  activity  in 
terms  of  a  specific  instance  of  a  DEPARTMENT  or  DIVISION 
object  and  the  OBILLET  and  EBILLET  objects  contained 
therein.  OBILLET  and  EBILLET  objects  are  then  viewed  as 
containing  one  or  more  instances  of  OFFICER  and  ENLISTED 
objects,  respectively. 

Personnel  are  viewed  as  instances  of  OFFICER  or 
ENLISTED  objects.  At  the  Executive  level,  officer  personnel 
are  viewed  as  assigned  to  one  or  more  specific  instances  of 
OBILLET  object,  and  enlisted  personnel  to  a  specific 
instance  of  DEPARTMENT  object  or  DIVISION  object.  At  the 
Department  and  Division  levels,  enlisted  personnel  are 
viewed  as  assigned  to  one  or  more  specific  instances  of 
EBILLET  object.  An  officer  or  enlisted  individual  may  be 
temporarily  unassigned  to  a  billet  or  assigned  to  a  billet 
with  another  individual  (see  previous  footnotes) . 

B.  FUNCTIONAL  REQUIREMENTS 

The  AMA/PMS  consists  of  a  single  application  with  two 
main  processes,  the  Manage  Manpower  process  and  the  Create 
Reports  process.  (Appendix  C,  Figures  C-1  and  C-2) . 

1.  Manage  Manpower  Process 

This  process  is  divided  into  two  lower  level 
processes.  Manage  Billet  Objects  and  Manage  Personnel 
Objects.  (Appendix  C,  Figures  C-3  and  C-4). 
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a.  Manage  Billet  Objects 

This  lower  level  process  contains  the  mechanisms 
for  creating,  modifying,  and  deleting  instances  of  OBILLET 
and  EBILLET  objects.  Using  source  documents  such  as  the  MPA 
(OPNAV  1000/2)  or  notification  letters  from  Resource 
Sponsors,  the  user  will  be  able  to  maintain  all  billet  data 
used  by  the  AMA/PMS.  Instances  of  OBILLET  and  EBILLET 
obi^cts  will  be  created,  modified  and  deleted  in  this 
process.  Instances  of  DEPARTMENT  and  DIVISION  objects  will 
be  created  via  the  Create  OBILLET  and  Create  EBILLET 
processes.  DEPARTMENT  and  DIVISION  objects  can  be  modified 
and  deleted  independent  of  the  Update  OBILLET  and  Update 
EBILLET  processes.  (Appendix  C,  Figures  C-6  through  C-10) . 

b.  Manage  Personnel  Objects 

Using  data  gleaned  from  PCS  orders,  ODCR,  EDVR, 
personnel  service  records,  etc.,  this  process  provides  the 
mechanisms  for  managing  the  personnel  data  used  by  the 
AMA/PMS.  Instances  of  the  OFFICER  and  ENLISTED  objects  will 
be  created,  modified,  and  deleted  in  this  process. 

(Appendix  C,  Figures  C-11  through  C-14) . 

2.  Create  Reports  Process 

The  second  major  component  of  the  AMA/PMS  is  the 
Create  Reports  Process.  (Appendix  C,  Figure  C-15) .  By 
using  data  stored  in  the  database  by  the  Manage  Manpower 
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Process,  the  system  generates  reports.  These  reports 
provide  various  views  of  the  data  for  use  in  analyzing  an 
activity's  manpower. 

Nine  standard  report  outputs  are  produced  by  the 
AMA/PMS.  (Appendix  C,  Figures  C-15  thourgh  C-21  and 
Appendix  D,  Figures  D-5  through  D-11) .  There  are  two 
general  types  of  reports  generated  by  the  Generate  Reports 
process:  Manning  Reports  and  Status  Reports. 

a .  Maiming  Reports 

Manning  Reports  provide  information  linking  an 
officer  or  enlisted  member  directly  to  one  or  more 
authorized  billets.  The  Department/Division  Manning  Report 
will  be  created  by  drawing  required  data  from  instances  of 
ENLISTED  object,  and  DEPARTMENT  object.  Officer  Manning 
Report  will  contain  information  gleaned  from  instances  of 
OFFICER  object  and  DEPARTMENT  object.  The  Personnel 
Gains/Losses  Report  will  draw  on  the  OFFICEIR  and  ENLISTED 
objects  to  produce  a  report  showing  those  personnel  known  to 
be  ordered  to  the  activity  but  not  yet  received,  and  those 
personnel  whose  PRDs  are  within  six  months  of  the  date  of 
the  report.  (Appendix  D,  Figures  D-5  through  D-7) . 

b .  Status  Reports 

Status  Reports  provide  a  numeric  overview  of  an 
activity  in  terms  of  billets  authorized  and  personnel 
assigned.  The  system  will  focus  on  various  properties  within 
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an  object  depending  on  the  status  report  being  produced.  It 
will  then  calculate  the  number  of  times  that  property  : 

in  the  instances  of  an  object. 

Five  status  reports  are  generated  by  the  system. 
The  Officer  Status  Report  provides  information  on  authorized 
officer  billet  levels  and  the  number  of  officer  personnel 
assigned  to  the  activity.  The  Department/Division  Status 
Report  provides  the  same  comparison  for  enlisted  personnel. 
The  Paygrade  Status  Report  is  a  comparison  between  the 
number  of  billets  authorized  for  each  enlisted  and  officer 
paygrade  and  the  number  of  personnel  assigned  within  each 
paygrade.  The  Designator /Rat ing  Status  Report  provides  a 
comparison  between  the  number  of  billets  authorized  for  each 
officer  designator  and  each  enlisted  rate  and  the  number  of 
personnel  assigned,  broken  down  by  paygrade.  (Appendix  D, 
Figures  D-8  through  D-11). 

C.  SUMMARY 

This  chapter  provided  a  brief  overview  of  Object 
Oriented  Database  Analysis  methodology.  Data  requirements 
for  the  AMA/PMS  are  presented  as  Objects  in  Appendix  A,  and 
defined  in  Object  Specifications  presented  in  Appendix  B. 
Function  requirements  for  the  system,  the  data  used  in  these 
processes  and,  the  objects  created  and  used  were  examined  in 
detail.  Data  Flow  Diagrams  (DFD)  for  the  AMA/PMS  are 
presented  in  Appendix  C. 
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Chapter  IV  will  present  the  logical  database  design 
using  Object  Oriented  methodology  and  the  Relational 
Database  Model. 
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IV.  DATABASE  DESIGN 


In  Chapter  III  the  functional  and  data  requirements  for 
the  AMA/PMS  were  specified.  Using  an  object  oriented 
database  methodology,  the  entities  in  the  user's  environment 
are  represented  as  objects  to  be  stored  in  the  database. 

The  functional  requirements  of  the  system  are  represented  by 
data  flow  diagrams  showing  how  objects  are  created, 
modified,  deleted,  and  displayed  and  who  is  authorized  to  do 
what  on  these  objects. 

In  this  chapter,  the  logical  database  and  application 
design  are  presented.  In  the  logical  design  phase,  database 
objects,  as  defined  in  the  user's  requirements  phase,  are 
transformed  into  a  relational  diagram.  In  the  application 
design  phase,  menu  structures,  detailed  forms  and  reports, 
and  pseudo  code  for  application  programs  are  developed  for 
the  data  flow  diagrams  developed  in  the  user's  requirement 
phase . 

A.  LOGICAL  DATABASE  DESIGN 

1.  Relational  Database  Model 

The  Relational  Database  Model  is  the  approach  used 
to  organize  the  data  in  the  logical  design.  "The  relational 
database  model  is  based  on  the  concept  that  data  is  stored 
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(at  least  conceptually)  in  two-dimensional  tables  called 
relations.  Each  row  in  the  table  represents  a  record", 
i.e.,  an  instance  of  an  entity.  "Each  column  represents  a 
field"  or  characteristic  of  an  entity.  ".  .  .A  column  is 
called  an  attribute".  [Ref.  4:Chap  5].  Each  table  is 
generally  referred  to  as  a  file. 

There  are  restrictions  placed  on  relations,  however. 
"First,  attributes  are  single  valued;  neither  repeating 
groups  nor  arrays  are  allowed.  Second,  entries  in  any 
column  are  all  of  the  same  kind".  [Ref.  4: Chap  5].  For 
example,  for  each  record  (row)  in  a  file  (table)  there  would 
be  only  a  single  entry  in  the  column  (attribute)  called 
'age'.  No  two  records  in  a  file  may  be  identical. 

2.  Object  Relationships 

First,  in  order  to  convert  objects  into  relations, 
the  analyst  examines  the  relationships  among  the  objects  and 
constructs  a  preliminary  relational  diagram.  It  should  be 
noted  that  there  is  not  necessarily  a  one  to  one  correlation 
when  converting  objects  into  relations.  Next,  all  relations 
are  normalized  to  eliminate  modification  anomalies. 
Additional  relations  will  need  to  be  created  to  to 
accomplish  normalization. 

The  relationships  between  relations  are  determined 
from  the  types  of  objects  from  which  they  are  derived. 

These  relationships  are  classified  as  one  to  one,  one  to 
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many,  and  many  to  many,  and  apply  only  to  the  relationship 
between  any  two  relations.  Relationships  between  relations 
further  are  designated  as  either  mandatory  or  optional. 

In  a  one  to  one  relationship,  the  key  of  either 
relation  is  placed  into  the  other  as  a  foreign  key.  In  a 
one  to  many  (parent  to  child)  relationship,  the  key  of  the 
parent  is  placed  into  the  child  relation  as  a  foreign  key. 

An  intersection  relation  is  created  to  represent  a  many  to 
many  relationship.  The  key  of  an  intersection  relation  is 
the  composite  key  of  both  of  the  parent  relations. 

3.  Relational  Diagram 

Trom  the  Object  Diagram  and  Object  Specifications 
defined  in  Chapter  III  and  Appendices  A  and  B,  relations  and 
relation  definitions  are  produced.  Appendix  E  is  the 
Relational  Diagram  for  the  AMA/PMS.  It  graphically 
represents  the  relationships  between  relations  as  derived 
from  the  Object  Diagrams  in  Appendix  A.  Appendix  F  contains 
the  Relation  Definitions  and  the  physical  description  of  the 
Domain  Definitions  only. 

All  of  the  objects  defined  for  the  AMA/PMS,  Appendix 
A,  are  compound  objects.  Each  contains  at  least  one  object 
property  which  is  either  single  or  multi-valued.  The 
OFFICER  and  ENLISTED  objects  are,  additionally,  composite 
objects  as  they  contain  a  multi-valued,  non-object  property. 
The  intersection  relation  DIVASSIGN  is  created  to  represent 
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the  many  to  many  relationship  between  DIVISION  and  OFFICER. 
The  intersection  relations  OASSIGN  and  EASSIGN  were  defined 
in  order  to  represent  the  many  to  many  relationship  between 
the  compound  objects;  OFFICER  and  OBILLET,  and  ENLISTED  and 
EBILLET,  respectively;  which  contain  each  other  as  object 
properties.  The  relation  COLDUTIES  was  created  to 
illustrate  the  composite  object  relationships  between 
OFFICER  and  ENLISTED  and  their  multi-valued,  non-object 
property  COLDUTY.  (Appendix  E) . 

In  the  Relational  Diagram,  Appendix  E,  the  key  for 
each  relation  is  indicated  by  an  underlined  attribute.  A 
foreign  key  is  identified  by  an  asterisk.  The  key  for  an 
intersection  relation  is  the  key  for  each  jf  the  parent 
relations,  indicated  by  an  underline  and  an  asterisk.  A 
mandatory  relationship  is  represented  by  a  bar  on  the 
connecting  line  and  an  optional  relationship  by  a  circle. 

4.  Normalized  Relations 

All  relations  in  the  AMA/PMS  are  in  Boyce-Codd 
Normal  Form.  The  relations  have  been  developed  to  avoid 
modification  anomalies  which  are  undesirable  consequences 
resulting  from  changing  the  data  in  relations.  There  are 
three  types  of  modification  anomalies:  deletion,  insertion, 
and  update. 

A  deletion  anomaly  is  caused  when  deletion  of  the 
facts  about  one  entity  inadvertently  causes  the  deletion  of 
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facts  about  another  entity.  For  example,  if,  in  the 
AMA/PMS,  an  officer  record  is  deleted  and  a  billet  record  is 
also  mistakenly  deleted  this  is  a  deletion  anomaly. 

An  insertion  anomaly  would  exist  if,  for  example,  a 
billet  record  could  not  be  entered  into  the  database  until 
an  officer  or  enlisted  person  was  assigned  to  the  billet. 
This  should  result  in  an  incomplete  database  for  billet 
structure . 

An  update  anomaly  occurs  when  redundancy  of  data  is 
required  based  on  the  database  structure.  For  example,  if 
an  individual  is  assigned  to  more  than  one  billet  and  a 
separate  record  on  the  individual  is  created  in  the  file  for 
each  billet  held.  If  data  needed  to  be  changed  on  the 
individual,  such  as  rank,  then  for  each  billet  record  on  the 
individual,  a  change  would  have  to  be  made.  This  requires 
too  much  record  updating  for  a  simple  data  change. 

To  solve  these  anomalies,  using  the  above  examples, 
three  relations  would  be  created;  one  containing  personal 
information  on  an  individual  and  one  containing  billet 
information,  and  an  intersection  relation  linking  an 
individual  to  a  specific  billet(s). 


47 


B.  RELATIONSHIP  DESCRIPTIONS 


1 .  DEPARTMENT 

The  DEPARTMENT  object  is  a  compound  object  as  it 
contains  the  object  properties  of  DIVISION,  OFFICER, 
ENLISTED,  OBILLET,  and  EBILLET.  All  are  multi-valued. 
Because  DEPARTMENT  is  a  compound  object,  the  key  to  this 
relation,  DName,  is  placed  as  a  foreign  key  in  each  of  its 
child  relations.  All  of  the  relationships  between 
DEPARTMENT  and  its  child  relations  are  one  to  many.  A 
DEPARTMENT  may  have  multiple  values  of  DIVISION,  OFFICER, 
ENLISTED,  OBILLET,  and  EBILLET.  Each  of  these  child 
relations  is,  however,  associated  with  only  one  DEPARTMENT. 

a.  DEPARTMENT  and  DIVISION 

The  relationship  between  DEPARTMENT  and  DIVISION 
is  mandatory/optional .  A  DIVISION  must  belong  to  a 
DEPARTMENT,  but  a  DEPARTMENT  may  not  have  any  DIVISIONS 
assigned,  such  as  the  Safety  Department  in  an  aviation 
squadron . 

Jb.  DEPARTMENT  and  OFFICER 

The  relationship  between  DEPARTMENT  and  OFFICER 
is  mandatory/optional.  An  OFFICER  must  be  assigned  to  a 
DEPARTMENT,  but  a  DEPARTMENT  might  not  necessarily  have  an 
OFFICER  assigned  at  all  times  or  may  have  several  OFFICERS 
assigned . 
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c.  DEPARTMENT  and  ENLISTED 


The  relationship  between  DEPARTMENT  and  ENLISTED 
is  the  same  as  that  for  OFFICER,  one  to  many  and 
mandatory/optional . 

d.  DEPARTMENT  and  OBILLET 

The  relationship  between  DEPARTMENT  and  OBILLET 
is  mandatory /mandatory  as  all  DEPARTMENTS  must  have  at  least 
one  OBILLET  assigned  and  an  OBILLET  is  always  associated 
with  a  DEPARTMENT. 

e.  DEPARTMENT  and  EBILLET 

Between  DEPARTMENT  and  EBILLET,  however,  the 
relationship  is  mandatory/optional .  An  EBILLET  must  be 
associated  with  a  DEPARTMENT,  but  a  DEPARTMENT  need  not  have 
any  or  may  have  several  EBILLETS  assigned. 

2.  DIVISION 

DIVISION  is  a  compound  object  containing  the  object 
properties  OFFICER,  ENLISTED,  OBILLET  and  EBILLET.  Each  of 
these  object  properties  is  multi-valued.  The  key  to  the 
DIVISION  relation,  DivName,  is  placed  as  a  foreign  key  in 
each  of  its  child  relations. 

a.  DIVISION  and  OFFICER 

The  relationship  between  DIVISION  and  OFFICER  can 
be  many  to  many.’  This  relationship  is  illustrated  through 

^This  is  not  often  done  and  usually  is  a  result  of  manning 
shortfalls. 
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the  creation  of  an  intersection  relation  called  DIVASSIGN. 
Its  key  is  the  composite  key,  DivName  and  SSN  (SSN  is  the 
key  to  OFFICER) .  More  than  one  OFFICER  may  be  assigned  to  a 
DIVISION,  optional  relationship,  and  an  OFFICER  may  be 
assigned  as  a  Division  Officer  to  more  than  one  DIVISION 
(also  an  optional  relationship)*. 

b.  DIVISION  and  OBILLET 

The  relationship  between  DIVISION  and  OBILLET  is 
optional/optional.  A  DIVISION  (or  workcenter)  need  not  have 
OBILLETs  associated  with  it,  for  example  the  Career 
Counseling  Division,  and  an  OBILLET  may  be  assigned  only  to 
a  DEPARTMENT  and  not  a  DIVISION. 

c.  DIVISION  cind  ENLISTED /EBILLET 

DIVISION  is  related  to  both  ENLISTED  and  EBILLET 
in  a  one  to  many,  mandatory/optional  relationship.  An 
ENLISTED  must  be  assigned  to  a  DIVISION,  although  it  is 
possible  that  a  DIVISION  has  no  ENLISTED  associated.  Many 
ENLISTED  may  be  assigned  to  a  DIVISION,  but  an  ENLISTED 
person  is  generally  assigned  to  only  one  DIVISION. 

EBILLET  must  be  associated  with  DIVISION,  however 
DIVISION  need  not  contain  EBILLETs. 


*A  Department  Head  is  not  necessarily  a  Division  Officer. 

"As  stated  previously,  billets  may  be  assigned  to  a  Department 
for  administrative  support. 
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3.  OFFICER  and  OBILLET 


OFFICER  is  a  composite  and  compound  object.  OFFICER 
contains  Collateral  Duties  as  a  multi-valued,  non-object 
property.  This  relationship  is  illustrated  by  the  COLDUTY 
relation.  The  composite  key  of  this  relation  is  SSN  from 
OFFICER  and  Colduty.  Certain  collateral  duties  must  be 
assigned  to  OFFICER,  but  not  all  OFFICERS  are  required  to 
hold  collateral  duties.  Thus  the  mandatory/optional 
relationship. 

OFFICER  contains  OBILLET  as  a  multi-valued  object 
property,  and  OBILLET  contains  OFFICER  in  the  same  manner. 
This  creates  compound  objects  with  a  many  to  many 
relationship.  In  order  to  avoid  update  anomalies,  an 
intersection  relation  called  OASSIGN  is  created.  Its  key  is 
the  composite  key,  SSN  and  BSC  (BSC  is  the  key  for  OBILLET) . 
An  OFFICER  may  be  assigned  to  more  than  one  OBILLET  or  none 
at  all.  OBILLET  may  be  allotted  to  more  than  one  OFFICER  or 
to  none  at  all.'^' 

4.  ENLISTED  and  EBILLET 

ENLISTED  is  a  composite  and  compound  object. 

ENLISTED  contains  Collateral  Duties  as  a  multi-valued,  non¬ 
object  property.  This  relationship  is  illustrated  by  the 
COLDUTY  relation.  The  composite  key  of  this  relation  is  SSN 


"'For  a  period  of  time  two  officers  may  be  assigned  to  the  same 
billet  if  one  is  relieving  (replacing)  the  other.  A  billet  may  be 
gapped  (unfilled)  during  manning  shortfalls. 
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from  ENLISTED  and  Colduty.  Certain  collateral  duties  must 
be  assigned  to  ENLISTED  but  not  all  ENLISTEDs  are  required 
to  hold  collateral  duties.  Thus  the  mandatory/optional 
relationship. 

ENLISTED  contains  EBILLET  as  a  multi-valued  object 
property,  and  EBILLET  contains  ENLISTED  in  the  same  manner. 
This  creates  compound  objects  with  a  many  to  many 
relationship.  In  order  to  avoid  update  anomalies,  an 
intersection  relation  called  EASSIGN  is  created.  Its  key  is 
the  composite  key,  SSN  and  BSC  (BSC  being  the  key  for 
EBILLET) .  An  ENLISTED  may  be  assigned  to  more  than  one 
EBILLET  or  not  at  all,  EBILLET  may  be  allotted  to  more  than 
one  ENLISTED  or  none  at  all." 

C.  APPLICATION  DESIGN 

The  application  design  phase  is  the  final  step  in 
logical  database  design.  First,  the  number  of  applications 
and  application  scope  are  determined.  For  the  AMA/PMS, 
there  are  two  applications.  Manpower  Management  and  Reports. 
The  Manpower  Management  application  uses  all  object  views 
specified  in  Appendix  A  for  data  entry,  modification, 
display,  and  deletion.  The  Reports  application  manipulates 
the  data  within  the  database  to  produce  either  predefined 


"For  a  period  of  time  two  enlisted  personnel  may  be  assigned 
to  the  same  billet  if  one  is  relieving  (replacing)  the  other.  A 
billet  may  be  gapped  (unfilled)  during  manning  shortfalls. 
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reports  or  respond  to  user  ad  hoc  queries.  The  application 
design  process  entails  materialization  of  objects  into  data 
input  and  display/modify  screens  and  output  design.  Data 
outputs  are  in  the  form  of  predefined  reports.  Appendix  D. 
The  scope  of  the  application  is  specified  in  Appendix  G, 
Update,  Display  and  Control  Mechanisms. 

1.  Menu  Hierarchy 

Access  to  the  two  AMA/PMS  applications  will  be  menu- 
driven  for  ease  of  use.  The  menu  hierarchy.  Appendix  H, 
consists  of  three  layers  below  the  Main  Menu.  The  Main  Menu 
provides  initial  access  to  either  application,  Manpower  or 
Reports.  Design  materializations,  input  and  display/modify 
screens,  and  menu  logic  are  presented  in  Appendices  D  and  I, 
respectively . 

a .  Manpower  Menu 

The  Manpower  Menu,  provides  access  to  the  next  lower 
menu  layer  through  either  of  two  paths;  Billet  Data  or 
Personnel  Data. 

(1)  Billet  Data  Menu.  The  Billet  Data  Menu 
offers  the  user  the  choice  to  Add  New  Billet  data.  Edit 
Billet  Data,  or  Delete  an  existing  billet  record.  Any  of 
these  three  choices  leads  to  the  next  lower  menu  layer.  If 
the  user  desires  to  Add  New  Billet  data  the  system,  through 
the  Billet  Type  Menu,  will  allow  the  choice  of  either  an 
Officer  or  Enlisted  Billet  data  input  screen.  Selection  of 
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the  Edit  Billet  Data  or  the  Delete  Billet  option  leads  to  a 
menu  which  will  allow  a  choice  of  three  Billet  Display 
formats;  by  Department,  Division,  or  Billet  Sequence  Code 
(BSC) . 

The  Billet  Data  Menu  also  provides  direct 
access  to  the  Personnel  Data  Menu  and  to  the  Reports 
application  menu,  without  requiring  the  user  to  return  to 
the  previous  menu  layer;  and  allows  the  user  to  return  to 
the  Manpower  Menu.  The  Billet  Type  and  Billet  Display  menus 
allow  the  user  to  return  only  to  the  Billet  Data  Menu. 

(2)  Personnel  Data  Menu.  The  Personnel  Data 
Menu  presents  the  user  with  the  choice  to  Add  New  Personnel 
data.  Edit  Personnel  Data,  or  Delete  Personnel  data.  If  the 
user  chooses  to  Add  New  Personnel  an  additional  menu  will 
provide  the  user  the  choice  of  the  Officer  or  Enlisted 
Record  Type  input  screen.  The  Record  Type  menu  allows  the 
user  to  return  only  to  the  Personnel  Data  menu. 

The  Personnel  Data  Menu  also  provides 
direct  access  to  the  Billet  Data  Menu  and  to  the  Reports 
application  menu,  without  requiring  the  user  to  return  to 
the  previous  menu  layers;  and  allows  the  user  to  return  to 
the  Manpower  Menu. 

b.  Reports  Menu 

The  Reports  Menu,  provides  direct  selection  of 
the  Gains/Losses  Report  and/or  access  to  the  next  lower  menu 


54 


layer  through  either  of  two  paths;  Manpower  Reports  or 
Status  Reports.  Additionally,  the  user  may  request  Ad  Hoc 
queries  against  the  data  base.  All  reports  will  be 
displayed  on  screen  and  provide  the  user  the  option  to  print 
the  specified  report. 

(1)  Manpower  Reports  Menu.  This  menu  provides 
the  user  the  option  of  displaying  activity  enlisted  manpower 
information  either  by  Department  or  Division.  A  report  of 
the  activity  officer  manpower  is  also  an  option. 

The  Manpower  Reports  menu  provides  direct 
access  to  the  Status  Reports  Menu  or  to  the  Manpower  Menu  as 
well  as  the  previous  menu. 

C2J  Status  Reports  Menu.  This  menu  presents 
the  user  with  four  options  for  activity  enlisted  personnel 
status  reports;  by  Department,  Division,  Paygrade,  or 
Designator/Rate.  Officer  Status  Reports  is  an  additional 
menu  option. 

The  user  is  provided  direct  access  to  the 
Manpower  Reports  and  Manpower  Menus  as  well  as  the  option  to 
return  to  the  Reports  Menu. 

D.  CONTROL  MECHANISMS 

The  AMA/PMS  database  will  contain  information  protected 
under  the  Privacy  Act  as  well  as  Combat  Readiness  related 
information.  It  therefore  must  be  protected  by  a  computer 
security  system  that  as  a  minimum  consists  of  password 
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access  controls.  Additional  controls  on  the  system  consist 
of  data  integrity  requirements.  Data  integrity  will  be 
validated  against  tables  which  have  specified  allowable 
values  for  data  elements  such  as  Rate/Rank,  Designator, 
PNEC/SNEC,  and  BSC.  The  presence  of  data  in  Name,  SSN,  PRD, 
EAOS,  etc.  fields  will  be  the  control  mechanism  for  these 
data  elements.  The  field  for  Collateral  Duties  will  be  a 
free-form  comments  field.  Update,  Display  and  Control 
Mechanisms  are  specified  in  detail  in  Appendix  G. 

1.  Data  Input 

a.  Billets 

All  fields  on  the  Officer  Billet  Input  screen  are 
mandatory.  With  the  exception  of  the  PNEC  and  SNEC  fields 
on  the  Enlisted  Billet  input  screen,  all  fields  are 
mandatory . 

b .  Personnel 

Mandatory  fileds  on  officers  are  first  and  last 
names.  Grade  Designator,  SSN,  and  PRD.  For  enlisted 
personnel  the  mandatory  fields  are  first  and  last  name,  SSN, 
Rating,  paygrade.  Rate,  and  PRD.  All  other  fields  for  both 
inputs  are  optional. 

Billet  assignments  are  either  made  through  the 
input  mode  for  personnel  records  or  by  modifying  an  existing 
record . 
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2.  Data  Display,  Modification,  or  Deletion 

a.  Billet 

Billet  data  may  be  displayed  on  the  screen  by 
specifying  Department  or  Division.  The  user  then  scrolls 
through  the  data  as  needed.  Billet  data  may  also  be 
displayed  by  specifying  BSC.  Once  displayed,  billet  data 
may  be  modified  on  screen  or  deleted  from  the  database. 

b .  Personnel 

Personnel  data  may  be  displayed  on  the  screen  by 
specifying  the  personnel  record  desired  by  SSN  or  by  Name 
and  Grade/Rating  combination.  Once  displayed,  personnel 
records  may  be  modified  or  deleted  from  the  database. 

c.  Reports 

All  pre-defined  report  formats  will  be  displayed 
on  screen.  Information  in  the  reports  cannot  be  modified  or 
deleted  from  the  reports  process. 

E.  SUMMARY 

This  chapter  presented  the  logical  database  design  for 
the  AMA/PMS  using  Object  Oriented  Database  Design 
methodology  and  the  Relational  Database  Model.  All  objects 
specified  in  Appendix  A,  were  transformed  into  normalized 
relations.  These  relations  contain  no  modification 
anomalies.  The  relationships  between  these  relations  are 
illustrated  in  Appendix  E  and  described  in  Section  B  of  this 
chapter.  Database  control  mechanisms  are  described  in 
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Appendix  G.  Input/Display  screens.  Menu  Hierarchy  and  menu 
samples,  and  menu  logic  (pseudo  code)  are  presented  in 
Appendices  D,  H,  and  I,  respectively. 
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V. 


SUMMARY  AMD  CONCLUSIONS 


A.  SUMMARY 

With  ever  increasing  DOD  budget  cuts,  the  need  to 
actively  manage  limited  manpower  assets  is  vital  to 
successful  accomplishment  of  the  Navy's  mission.  The 
information  needed  for  manpower  analysis  at  the  activity 
level  is  readily  available  in  documents  published  by  higher 
authority:  MPA,  ODCR,  and  EDVR.  However,  this  information 
is  rarely  used  to  manage  manpower  because  of  a  lack  of 
knowledge  on  the  part  of  COs,  XOs,  Department  Heads,  and 
Division  Officers  on  the  mechanisms  and  importance  of  the 
process . 

Failure  to  manage  manpower  at  the  activity  level  can 
have  serious  negative  impact  on  mission/combat  readiness. 
Conversely,  proactive  manpower  analysis  can  avert  serious 
manning  shortfalls. 

Object  oriented  methodology  was  used  to  fully  define 
functional  and  data  requirements.  Data  requirements  are 
presented  in  Appendix  A,  Object  Diagrams;  and  Appendix  B, 
Object  Definitions.  Dataflow  diagrams  for  the  AMA/PMS  are 
presented  in  Appendix  C.  System  output/report  formats  are 
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presented  in  Appendix  D.  Functional  requirements  are 
described  in  Appendix  G,  Update,  Display,  and  Control 
Mechanisms . 

The  Relational  Database  Model  was  used  as  a  design  tool. 
Objects  were  transformed  into  relations  in  Boyce-Codd  Normal 
Form,  thereby  eliminating  all  possible  modification 
anomalies.  The  design  specifications  are  presented  in 
Chapter  IV.  The  Relational  Diagram  and  Relation  Definitions 
are  presented  in  Appendices  E  and  F,  respectively.  The 
AMA/PMS  is  designed  to  be  menu  driven.  The  Menu  Hierarchy 
and  Menu  Logic  (pseudo  code)  are  contained  in  Appendices  H 
and  I . 

B .  ALTERNATIVE  FUNCTIONALITY 

The  AMA/PMS  is  designed  strictly  to  manage  activity 
level  active  duty  military  manpower.  The  design  can  easily 
be  modified,  after  requirements  have  been  specified,  to 
accommodate  civilian  and/or  reserve  manpower. 

Additional  functionality  could  be  gained  by  designing 
system  interfaces  to  allow  mainframe  to  personal  computer 
down-load  of  billet  information  from  NMDAS,  enlisted 
personnel  data  from  NES,  and  officer  personnel  data  from 
OPINS.  Some  modification  of  domain  definitions  would  be 
required  to  ensure  data  compatability .  This  would 
significantly  reduce  data  input  time  to  the  database. 


60 


APPENDIX  A:  OBJECT  DIAGRAMS 


DEPARTMENT 


DName 


DIVISION 

^  MV 

1  OFFICER  1 

MV 

[?NLISTED 

1 

MV 

OBILLET 

MV 

EBILLET 

MV 


DIVISION 


DivName 

DEPARTMENT 

1 

OFFICER 

hi^/ 

1 

ENUSTED 

1  MV 

1 

OBILLET 

MV 

1 

EBILLET 

MV 

OBILLET 


BSC 

Billet  Title 
Grade 
Designator 
BA _ 

1  DEPARTMENT 


DIVISION 


OFRCER 

-  MV 


EBILLET 


BSC 

Billet  Title 

Rating 

Paygrade 

Rate 

PNEC 

SNEC 

BA _ 

I  DEPARTMENT 


DIVISION 


ENLISTED 

-  MV 


OFFICER 


SSN 

Name 

Grade 

Designator 

PRD 

Date  of  Rank 
Collateral  Duties 

MV 


MV 


DEPARTMENT 


DIVISION 


OBILLET 


MV 


ENLISTED 


SSN 

Name 

Rating 

Paygrade 

Rate 

PNEC 

SNEC 

PRD 

EAOS 

Date  of  Rank 
Time  in  Service 
Collateral  Duties 

MV 

DEPARTMENT 


DIVISION 


EBILLET 

- ^MV 


Figure  A-1:  Object  Diagrams 


61 


62 


APPENDIX  B:  OBJECT  DEFINITIONS 


OBJECT  DEFINITIONS 

1.  Department  Object 

DName;  Department  name 

DIVISION;  DIVISION  object;  MV;  SUBSET  {DivName, 
OBILLET,  EBILLET} 

OFFICER;  OFFICER  object;  MV;  SUBSET  {Name,  Grade, 
Designator,  PRD} 

ENLISTED;  ENLISTED  object;  MV;  SUBSET  {Name,  Rating 
Rate,  Rank,  PNEC,  SNEC,  PRD,  EAOS} 

OBILLET;  OBILLET  object;  MV;  SUBSET  {BSC,  Billet 
Title,  Grade,  BA} 

EBILLET;  EBILLET  object;  MV;  SUBSET  {BSC,  Billet 
Title,  Rating,  BA} 

2.  Division  Object 

DivName;  Division  name 

DEPARTMENT;  DEPARTMENT  object;  SUBSET  {DName} 

OFFICER;  OFFICER  object;  MV;  SUBSET  {Name,  Grade, 
Designator,  PRD} 

ENLISTED;  ENLISTED  object;  MV;  SUBSET  {Name,  Rating 
Rate,  Rank,  PNEC,  SNEC,  EAOS} 

OBILLET;  OBILLET  object;  M\';  SUBSET  {BSC,  Billet 
Title,  Grade,  BA} 


EBILLET;  EBILLET  object;  MV;  SUBSET  {BSC,  Billet 
Title,  Rating,  BA} 

3.  Obillet  Object 

BSC;  Billet  Sequence  Code 
Billet  Title;  Name  of  billet 
Grade;  Officer  ran)c  required  for  billet 
Designator;  Warfare  speciality  required  for  billet 
BA;  Billet  Authorization,  number  of  billets 
authorized;  MV 

DEPARTMENT;  DEPARTMENT  object;  SUBSET  {DName} 
DIVISION;  DIVISION  object;  SUBSET  {DivName} 
OFFICER;  OFFICER  object;  MV;  SUBSET  {Name,  Grade, 
Designator,  PRD} 

4.  Ebillet  Object 

BSC;  Billet  Sequence  Code 
Billet  Title;  Name  of  billet 

Rating;  Technical  speciality  required  for  billet 
Paygrade;  Paygrade  required  for  billet 

Rate;  Alpha-numeric  combination  of  Rating 
and  Paygrade  required  for  billet 
PNEC;  Primary  Naval  Enlisted  Classification  Code 
SNEC;  Secondary  Naval  Enlisted  Classification  Code 
BA;  Billet  Authorization,  number  of  billets 
authorized;  MV 

DEPARTMENT;  DEPARTMENT  object;  SUBSET  {DName} 
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DIVISION;  DIVISION  object;  SUBSET  {DivName} 

ENLISTED;  ENLISTED  object;  MV;  SUBSET  {Name,  Rating, 
Rank,  Rate,  PNEC,  SNEC,  PRD} 

5.  Officer  Object 

SSN;  Officer's  Social  Security  Number 
Name;  Officer's  full  name 
Grade;  Officer's  Rank 
Designator;  Warfare  designator 
PRD;  Projected  Rotation  Date 
Date  of  Rank;  date  promoted  to  current  rank 
Colduties;  Comments  or  collateral  duties;  MV 
DEPARTMENT;  DEPARTMENT  object;  SUBSET  {DName} 
DIVISION;  DIVISION  object;  SUBSET  {DivName} ;  MV 
OBILLET;  OBILLET  object;  MV;  SUBSET  {bsc,  billet 
title} 

6.  Enlisted  Object 

SSN;  Enlisted's  Social  Security  Number 
Name;  Enlisted's  full  name 
Rating;  Individual's  technical  speciality 
Paygrade;  Individual's  paygrade 

Rate;  Alpha-numeric  combination  of  individual's 
Rating  and  Paygrade 

PNEC;  Primary  Naval  Enlisted  Classification  Code 
SNEC;  Secondary  Naval  Enlisted  Classification  Code 
PRD;  Projected  Rotation  Date 
EAOS;  Date  -  End  Active  Obligated  Service 
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Date  of  Rate;  date  promoted  to  current  rate 
Time  in  Service;  Number  of  years,  months,  days 
enlisted  in  Navy 

Colduties;  Comments  or  collateral  duties;  MV 
DEPARTMENT;  DEPARTMENT  object;  SUBSET  {DName} 
DIVISION;  DIVISION  object;  SUBSET  {DivName} 
EBILLET;  EBILLET  object;  MV;  SUBSET  {bsc,  billet 
title} 

B.  DOMAIN  DEFINITIONS 

1 .  ba : 

Numeric  4 

Number  of  Billets  Authorized 

2.  billet  title: 

Text  20 

Title  of  authorized  billet  as  it  appears  on  the 
OPNAV  1000/2 

3.  bsc: 

Numeric  5 

Billet  Sequence  Code  as  it  appears  on  the  OPNAV 
1000/2 

4.  cob: 

Numeric  4 

Number  of  personnel  Currently  on  Board 

5.  date: 

Numeric,  mask  yymmdd, 
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where  yy  is  any  2  digits,  mm  is  any  2  digits  from 
01  to  12,  dd  is  any  2  digits  from  01  to  31. 

6.  date  of  rank: 

Same  as  number  5  above 

7.  date  of  rate: 

Same  as  number  5  above 

8.  designator: 

Numeric  4 

Four  digit  code  representing  an  Officers  warfare 
specialty 

9.  divname: 

Text  15 

Name  of  a  division  as  it  appears  on  the  OPNAV  1000/2 

10.  dname: 

Text  15 

Name  of  a  department  as  it  appears  on  the  OPNAV 
1000/2 

11.  grade: 

Text  4,  mask  XXXX 

where  XXXX  is  one  of:  FADM,  ADM,  VADM,  RAMU, 

RAML,  CAPT,  CDR,  LCDR,  LT,  LTJG ,  ENS,  CW04 ,  CW03 , 
CW02 

Grade  title  of  a  Comissioned  Officer 

12.  name: 

text  40:  Mask: 
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first  name;  Text  15 
mi;  Text  2 
last  name;  Text  23 
Full  name  of  all  personnel  assigned 

13.  nec: 

Numeric  4 

Naval  Enlisted  Classification  Code  as  found  in  the 
NEC  Manual  or  on  the  OPNAV  1000/2  (used  for  Primary 
and  Secondary  NEC  (PNEC/SNEC) ) 

14.  paygrade: 

Text  5,  mask  XXXXX, 

where  XXXXX  is  one  of : E9 ,  E8 ,  E7 ,  E6 ,  E5,  E4 , 
E1-E3 

Paygrade  of  Enlisted  Personnel 

15.  pnec: 

Numeric  4 

See  NEC  above. 

16.  pob: 

Numeric  4 

Projected  on  Board  number  of  personnel 

17.  prd: 

Text  5,  mask  AYYMM 

where  A  indicates  that  an  individual  is  has  not 
yet  arrived  on  board  (otherwise  this  digit  is 
blank),  YY  is  any  2  digits  from  00  to  99,  and  MM 
is  any  two  digits  from  01  to  12 
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Projected  Rotation  Date  of  personnel  assigned 


18 . 


19. 


20 . 


21 . 


rate : 

Text  5,  mask  XXXZZ 

where  XXX  is  enlisted  rate  and  ZZ  is  one  of:  1, 
2,  3,  C,  CS,  CM 

Enlisted  rating,  combination  of  enlisted  technical 
specialty  and  rate 
rating : 

Text  3 ,  mask  XXX 

where  XXX  is  an  enlisted  speciality  rating  as 
found  in  the  NEC  Manual, 
snec : 

Numeric  4 
See  NEC  above, 
ssn : 

Numeric  9 

Personnal  identification  number  assigned  by  the 
Social  Security  Administration 
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APPENDIX  C:  DATAFLOW  DIAGRAMS 


Legend. 

(1)  Billet  Data  (MPA  &  Notification  Letter) 

(2)  Personnel  Data  (ODCR.EDVR) 

(3)  Personnel  Data  (Personnel  Record) 

(4)  Department  Status  Report 

(5)  Division  Status  Repod 

(G)  Desiynaicr/natinQ  States  Repu’t 

(7)  Enlisted  Billet  Assignment 

(8)  Grade/Pay grade  Status  Report 


(9)  Deoartment  Manning  Report 

(10)  Division  Manning  Repo d 

(11)  Officer  Billet  Assignment 

(12)  Officer  Manning  Report 

(13)  Officer  Status  Report 

(14;  Personnel  Gams'Losses  Report 
(15)  Officer  and  Enlisted  PCS  Orders 


Figure  C-1:  AMA/PMS 
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Manpower 

Database 


LEGEND 

(11  3illel  Data  (MPA)  and  Notification  Letter 
(2'  Personnel  Data  tODCR  EDVR' 

(3i  Personnel  Data  (Personnel  Record' 

(4)  Officer  Billet  Assignment 

(5)  Enlisted  Billet  As^nment 

(6)  OBILlET  Ob|ecl 

(7)  EBILLET  Obiecl 
(81  OFFICER  Obiect 

(9)  ENLISTED  Ob)ecl 

(10)  Officer  and  Enfcslod  PCS  Orders 


(11)  DEPAHTMEN'T  Ob.iect 

(12)  DIVISION  Obiect 

(13)  Grade/Paygrade  Slalus  Reoon 

(14)  Designator, Hating  Status  Retxjn 

(15)  Department  Status  Report 

(16)  Division  Status  Report 

(17)  Officer  Status  Report 

(18)  Officer  Manning  Report 

(19)  Dep'nment  Manning  Ftepon 

(20)  Ovision  Manning  Report 

(21)  Personnel  Gamsr  Losses  Ftepon 


Figure  C-2:  Manage  Manpower  and  Create  Reports  Processes 

Diagram 


71 


LEGEND 

EDVR  -  Enlisted  Distribution  Verification  Report 
ODCR  »  Officer  Distribution  Control  Report 
PCS  ^  Permanent  Change  of  Station 
AN.  SN,  FN  -  Airman.  Seaman.  Fireman 


Figure  C-3:  Manage  Manpower  (Update  Objects) 
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Database 


L£GEN'Q 

ODCR  -  Officer  Distribution  control  Report 
EDVR  -  Enlisted  Distribution  Verification  Report 
PCS  -  Permanent  Change  of  Station 
AN,  SN,  FN  -  Airman,  Seaman.  Fireman 


Figure  C-4:  Manage  Objects 
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OP-12 


Resource 
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OPNAV  1 000/2 


Update 

DEPARTMENT 
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OP-12 


Resource 

Sponsor 
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OPNAV  1000/2 


Update 

DIVISION 

Object 


Notification 

Letter 


Figure  C-5:  Update  DEPARTMENT  and  DIVISION  Objects 


7' 


Manpower 

Database 


Figure  C-5:  Add,  Modify,  and  Delete  DEPARTMENT  Object 


75 


Manpower 

Database 


Figure  C-7 :  Add,  Modify,  and  Delete  DIVISION  Object 
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Figure  C-8 :  Update  OBILLET  and  EBILLET  Objects 


Manpower 

Database 


Figure  C-9:  Add,  Modify,  and  Delete  OBILLET  Object 
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Manpower 

Database 


Figure  C-10:  Add,  Modify,  and  Delete  EBILLET  Object 


9 


LB3END 

ODCR  =  Officer  Distribution  Control  Report 
PCS  =  Permanent  Change  of  Station 


Figure  C-11;  Update  OFFICER  Objects 


80 


Manpower 

Database 


LEGEND 

ODCR  -  Officer  Distribution  Control  Report 
PCS  -  Permanent  Change  of  Station 


Figure  C-12"  Add,  Modify,  and  Delete  OFFICER  Object 


81 


EPMAC 


Department 

Head 


LKENP 

EDVR  =  Enlisted  Distribution  Verification  Report 
PCS  =  Permanent  Change  of  Station 
AN,  SN,  FN  =  Arnnan.  Seaman.  Fireman 


Figure  C-13:  Update  ENLISTED  Objects 
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Manpower 

Database 


L£Ci£ND. 

EDVR  -  Enlisted  Distribution  Verrfication  Report 
PCS  -  Permcinent  Change  of  Station 
AN.  SN,  FN  -  Airman.  Seaman.  Fireman 


Figure  C-14:  Add,  Modify,  and  Delete  ENLISTED  Objects 
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LEGEND 

(1) 

Grade/Paygrade  Status  Report 

(6) 

(2) 

Designator/Rating  Status  Report 

(7) 

(3) 

Officer  Manning  Report 

(8) 

(4) 

Officer  Status  Report 

(9) 

(5) 

Department  Manning  Report 

Division  Manning  Report 
Department  Status  Report 
Division  Status  Report 
Personnel  Gains/Losses  Report 


Figure  C-15:  Create  Reports  Process 
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Fiqure  C-16:  Create  Enlisted  Reports 
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Figure  C-17:  Create  Enlisted  Manning  Reports 
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Figure  C-18: 


Create  Enlisted  Status  Reports 
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Database 


Figure  C-19:  Create  Officer  Reports 


Ob|ect 


Figure  C-20:  Create  Other  Status  Reports 
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Figure  C-21:  Create  Other  Reports 
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APPENDIX  D:  SAMPLE  FORMS  AND  REPORTS 

ENLISTED  PERSONNEL  DATA  INPUT/CHANGE  FORM 

Last  Name  First  Name  Ml 

Rating  Paygrade  Rate 

PNEC  SNEC  SSN  PRD  TIR  TIS 

Comments  (Colaterial  Duties,  Watch  Section,  Qualifications) 

(Enter  RATING  and  PAYGRADE;  system  will  enter  RATE) 

BILLET  ASSIGNMENT 

Department 

BSC 

BILLET  ASSIGNMENT 

Department  Division 

BSC  Billet  Title 

Do  you  wish  to  add,  modify  or  delete  another  Enlisted  Record?  (A/M/D/NO) 

Figure  D-1:  Enlisted  Personnel  Data  Input/Change  Form 


Division 


Billet  Title 
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ENLISTED  BILLET  DATA  INPUT/CHANGE  FORM 


Department 


Division 


BSC  Billet  Title  Rating  Paygrade 

Rate  PNEC  SNEC 

BA  FY+1  FY+2  FY^3  FY^4  FY+5 

(Enter  RATiNG  and  PAYGRADE;  system  will  enter  RATE) 


Do  you  wish  to  add,  modify,  or  delete  an  Enlisted  Billet?  (A/M/D/NO) 


Figure  D-2 ;  Enlisted  Billet  Data  Input/Change  Form 
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OFFICER  PERSONNEL  DATA  INPUT/CHANGE  FORM 


BSC  Billet  Title 


Do  you  wish  to  add,  modify,  or  delete  another  Officer  Record?  (ATvf/D/NO) 


Figure  D-3 :  Officer  Personnel  Data  Input/Change  Form 
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OFFICER  BILLET  DATA  INPUT/CHANGE  FORM 


Department  Division 


BSC  Billet  Title  Gra  e  Desig 


BA  FY+1  FY^2  FY-r3  FY^4  FY+5 


Do  you  wish  to  add,  modify,  or  delete  an  Officer  Billet?  (A/M/D/NO) 


Figure  D-4 :  Officer  Billet  Data  Inpuc/Change  Form 
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DEPARTMENT  MANNING  REPORT 


REPORT  DATE 


DEPARTMENT:  OPERATIONS 


DIVISION:  F  DIVISION 


BSC 

BILLET 

TITLE 

RATE 

PTEC 

SNEC 

BA 

NAME 

RATE 

PNEC 

SNEC 

PRD/ 

EADS 

30060 

Signalman 

SMI 

1 

Jones,  R. 

SMI 

9203/ 

9406 

30070 

Signalman 

SM2 

2 

Petty,  T. 

SM2 

9212/ 

9406 

Kart,  E. 

SM3 

9303/ 

9406 

DEPARTMENT:  OPERATIONS  DIVISION:  DECK  DIVISION 


55060 

Boatsmate 

BM1 

1 

Kennedy,  C 

BM1 

9101/ 

9203 

55070 

BM  Basic 

SN 

9700  28 

Jones,  L. 

BMSN 

921  2/ 

9112 


Cathcart.  M.  SN  9303/ 

9406 


DIVISION  MANNING  REPORT 

DEPARTMENT:  OPERATIONS 


BSC 

BILLET 

RATE 

PNEC 

TITLE 

SNEC 

30060 

Signalman 

SMI 

30070 

Signalman 

SM2 

REPORT  DATE 

DIVISION:  F  DIVISION 


BA 

NAME 

RATE 

PNEC 

SNEC 

PRD/ 

EAOS 

1 

Jones,  R. 

SMI 

9203/ 

9406 

2 

Petty.  T. 

SM2 

921  2/ 
9112 

Figure  D-5:  Department/Division  Manning  Report 
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OFFICER  MANNING  REPORT  REPORT  DATE 

DEPARTMENT:  OPERATIONS 

BSC  BILLET  GRADE/DESIG  BA  NAME  GRADETDESIG  PRD 

TITLE 

30060  OPS  Officer  LCDR  1300  1  Jones,  R.  LCDR  1300  9406 

DIVISION:  SCHEDULES 

30070  Scheduler  LT  1300  2  Petty.  T.  LTJG  1305  9212 

DIVISION:  DET6 

30080  DETOIC  LCDR  1300  1  Kan,  E.  LCDR  1300  9303 


DEPARTMENT:  ADMINISTRATION 

55070  ADMIN  Officer  LCDR  1300  1  Jones,  L  LCDR  1300  9212 

55075  Legal  Officer  LT  1100  1  Cathcart,  M.  LT  1  105  9303 


Figure  D-6:  Officer  Manning  Report 
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GAINS  /  LOSSES  REPORT 

GAINS 


NAME 

GRADE 

RATE 

DESIG 

PNEC 

Jones, 

R. 

LT 

1300 

Smith, 

M. 

ENS 

1100 

Carry, 

D. 

ADCS 

LOSSES 


NAME 

GRADE 

DESIG 

RATE 

PNEC 

Calloway,  T. 

COR 

1300 

Mello,  C. 

LTJG 

1310 

REPORT  DATE 

EDA 

9002 
9010 
9008 

PRD 

9003 
9005 


Figure  D-7:  Gains/Losses  Report 
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DEPARTMENT  STATUS  REPORT 


REPORT  DATE 


DEPARTMENT:  MAINTENANCE 

DIVISION:  MAINT/PROD  CTL 


BSC 

BILLET 

RATE 

PNEC 

BA 

COB 

POB1 

POB2 

POB3 

POB4 

TITLE 

SNEC 

1  6050 

Maint  Coord 

ATCM 

8300 

1 

1 

1 

1 

1 

1 

1  6060 

Maint  Prod 

ATCS 

2 

2 

2 

3 

3 

2 

DIVISION: 

QUALITY  ASSURANCE 

18060 

QAREP 

ADI 

8318 

2 

1 

1 

2 

2 

2 

18070 

QAREP 

AMH1 

8380 

2 

3 

3 

3 

2 

2 

DIVISION:  MATERIAL  CONTROL 

1  9060  fvTTLCLK  AK1  3  3  3  2  2  2 


DIVISION  STATUS  REPORT  REPORT  DATE 


DEPARTMENT:  MAINTENANCE 
DIVISION:  POWER  PLANTS] 


BA 

BILLET 

TITLE 

RATE 

U 

o  o 

BA 

COB 

POB1 

POB2 

POB3 

POB4 

22070 

P/P  Repairman 

AD2 

8380 

6 

5 

5 

5 

5 

4 

22080 

P/P  Repairman 

AD3 

8318 

3 

4 

4 

4 

3 

3 

Figure  D-8:  Department/Division  Status  Report 
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OFFICER  STATUS  REPORT  REPORT  DATE 

DEPARTMENT:  SAFETY 


BSC 

BILLET 

GRADE/DESIG 

BA 

COB 

POB1 

POB2 

POB3 

POB4 

14010 

AV  Safety 

LT 

1311 

1 

1 

1 

1 

1 

0 

14020 

AV  Safety  Asst 

LTJG 

1311 

1 

1 

1 

1 

1 

1 

14030 

AV  Safety  Asst 

ENS 

1321 

1 

0 

0 

1 

1 

1 

DEPARTMENT:  MAINTENANCE 

DIVISION:  MAINT/PROD  CTL 

16010  A/CORGMNT  ENS  1311  1  1  1  1  1 


DIVISION:  MAINT  ADMIN 

17010  A/CORGMNT  ENS  1311 


1 


Figure  D-9:  Officer  Status  Report 
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GRADE/PAYGRADE  STATUS  REPORT  REPORT  DATE 

COMMAND  SUMMARY 

OFFICER 


GRADE 

BA 

COB 

% 

POB1 

POB2 

POB3 

POB4 

POB5 

POB6 

POB7 

CAPT 

1 

1 

1  00 

1 

1 

2 

1 

1 

1 

1 

CDR 

3 

3 

1  00 

3 

3 

3 

3 

3 

3 

3 

LCOR 

8 

8 

1  00 

8 

8 

8 

8 

8 

7 

7 

LT 

20 

18 

92 

21 

21 

20 

20 

20 

22 

22 

LTJG 

1  5 

12 

80 

12 

12 

13 

13 

13 

13 

13 

0JS 

8 

6 

75 

6 

6 

6 

6 

6 

6 

6 

CWO  2-4 

2 

2 

1  00 

2 

2 

2 

2 

2 

2 

2 

TOTAL 

57 

50 

87.7 

53 

53 

54 

53 

53 

54 

52 

enlisted 

PAYGRADE 

BA 

OOB 

% 

POE1 

P082 

POB3 

POB4 

POB5 

POB6 

POB7 

E9 

1 

1 

1  00 

1 

1 

2 

1 

1 

1 

1 

E8 

4 

3 

75 

3 

3 

3 

3 

3 

3 

3 

E7 

10 

12 

1  20 

8 

8 

8 

8 

8 

7 

7 

E5 

24 

20 

83.3 

21 

21 

20 

20 

20 

22 

20 

E5 

40 

35 

87.5 

32 

32 

33 

33 

33 

33 

33 

E4 

50 

42 

84 

6 

6 

6 

6 

6 

6 

6 

E1-3 

67 

55 

82 

52 

52 

52 

52 

52 

52 

52 

TOTAL 

1  96 

1  68 

85.7 

123 

123 

124 

123 

123 

124 

122 

Figure  D-10:  Grade/Paygrade  Status  Report 
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DESIGNATOR  /  RATING  STATUS  REPORT 


REPORT  DATE 


DESKS 

CADT  CDR 
BA/COB 

LCOR 

LT 

LTJG 

BS 

CW04  CW03  CW02  TOTAL 

1310 

1  / 1 

2/2 

3/2 

6/5 

1320 

6/7 

6/7 

131  1 

0/0 

1  000 

1  / 1 

1  / 1 

1  1  00 

2/1 

1  / 1 

3/2 

1520 

0/0 

TOTAL 

1  / 1 

2/2 

3/2 

9/9 

1  / 1 

1  6/15 

RATING 

PNEC  E9 
SNEC 

E8 

E7 

E6 

E5 

E4 

El -3 

TOTAL 

AD 

641  1 

1  /2 

1  /I 

1  / 1 

1/1 

4/5 

AO 

6418 

2/1 

2/2 

4/3 

AD 

6422 

4/3 

5/5 

7/6 

11/11 

27/25 

AD 

8318 

2/2 

3/4 

2/2 

7/8 

AD 

8300 

1  / 1 

2/2 

4/4 

3/3 

10/10 

TOTAL 

2/2 

11/11 

8/8 

16/15 

15/15 

52/51 

Figure  D-11:  Designator/Rating  Status  Report 


102 


103 


DEPARTMENT 


APPENDIX  E 


APPENDIX  F:  RELATION  DEFINITIONS 


Key:  BSC 

Foreign  Keys:  DName,  DivName 


7.  ©ASSIGN  (BSC,  SSN) 

Key:  BSC,  SSN 

8.  EASSIGN  (BSC,  SSN) 

Key:  BSC,  SSN 

9.  COLDUTY  (SSN,  Collaterial  Duties) 

Key:  SSN,  Collaterial  Duty 

B.  DOMAIN  DEFINITIONS 


1 . 

BA 

IN 

NUM(4) 

2  . 

Billet  Title 

IN 

CHAR (20) 

3  . 

BSC 

IN 

NUM(5) 

4  . 

COB 

IN 

NUM(4) 

5  . 

Date 

IN 

YYMMDD,  YY 

=  00-99; 

MM  =  1-12; 

DD  =  1-31 

6. 

Date  of  Rank 

IN 

YYMMDD,  YY 

=  00-30; 

MM  =  0-11; 

DD  =  0-30 

7  . 

Date  of  Rate 

IN 

YYMMDD,  YY 

=  00-30; 

MM  =  0-11; 

DD  =  0-30 

8. 

Designator 

IN 

NUM(4) 

9  . 

DivName 

IN 

CHAR(15) 

10. 

DName 

IN 

CHAR (15) 
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11.  Grade  IN 


12  . 

Name 

IN 

13  . 

NEC 

IN 

14  . 

Paygrade 

IN 

15. 

PNEC 

IN 

16. 

POB 

IN 

17  . 

PRD 

IN 

18. 

Rate 

IN 

19. 

Rating 

IN 

20. 

SNEC 

IN 

21. 

SSN 

IN 

CHAR(4);  FADM,  ADM,  VADM, 
RDMU,  RAML,  CART,  CDR, 

LCDR,  LT,  LTJG,  ENS,  CW04 , 
CW03 ,  or  CW02 
CHAR (40) 

NUM(4) 

CHAR(5);  E9,  E8,  E7 ,  E6 , 

E5,  E4,  E1-E3 
NUM(4) 

NUM(4) 

NUM(5);  YYMM,  A  =  "A"  or 
blank,  YY  =  00-99, 

MM  =  01-12 
Char (5) 

CHAR(5);  XXXZZ,  XXX  is  any 
enlisted  rate  and  ZZ  is  one 
of:  1,  2,  3,  C,  CS,  CM 
NUM(4) 

NUM(9) 
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APPENDIX  G;  UPDATE,  DISPLAY,  AND  CONTROL  MECHANISMS 


A.  UPDATE  MECHANISMS 

1.  OBILLET  Update  Mechanisms 

a.  Add  new  OBILLET  data 

(1)  Inputs 

-  List  of  authorized  billets  from  OPNAV 
1000/2  or  Notification  Letter  from  the 
appropriate  Resource  Sponsor. 

(2)  Outputs 

-  New  OBILLET  object  instance  in  database. 

(3)  Processing  notes 

-  Data  imported  enmasse  when  creating 
database . 

(4)  Volume 

-  10  to  500  billets  input  when  creating 
database . 

-  Usually  less  than  one  per  year. 

(5)  Frequency 

-  Once  per  year. 

b.  Edit  data  in  OBILLET 
1)  Inputs 

-  OBILLET  object  instance  from  database 
(including  DEPARTMENT  properties). 
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-  OBILLET  change  data  from  OPNAV  1000/2  or 
Notification  Letter  from  the  appropriate 
Resource  Sponsor - 

(2)  Outputs 

-  Modified  object  instance  to  database. 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  This  function  changes  all  OBILLET  data. 

(4)  Volume 

-  Unpredictable,  but  changes  rarely  occur. 

(5)  Frequency 

-  Once  per  year, 
c.  Delete  OBILLET  data 

(1)  Inputs 

-  List  of  billets  to  delete  from  OPNAV 
1000/2  or  Notification  Letter  from  the 
appropriate  Resource  Sponsor. 

-  OBILLET  object  instance  from  database. 

(2)  Outputs 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  Backup  of  existing  object  should  be  made 
prior  to  deletion. 

(4)  Volume 

-  Unpredictable,  but  deletions  rarely 
occur . 
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(5)  Frequency 

-  Less  than  once  per  year. 

2  .  EBILLET  Update  Mechanisms 

a.  Add  new  EBILLET  data 

(1)  Inputs 

-  List  of  authorized  billets  from  OPNAV 
1000/2  or  Notification  Letter  from  the 
appropriate  Resource  Sponsor. 

(2)  Outputs 

-  New  EBILLET  object  instance  in  database. 

(3)  Processing  notes 

-  Data  imported  enmasse  when  creating 
database . 

(4)  Volume 

-  20  to  5000  billets  input  when  creating 
database . 

-  Usually  less  than  one  per  year. 

(5)  Frequency 

-  Once  per  year. 

b.  Edit  data  in  EBILLET 
(1)  Inputs 

-  EBILLET  object  instance  from  database 
(including  DEPARTMENT  properties). 

-  EBILLET  change  data  from  OPNAV  1000/2  or 
Notification  Letter  from  the  appropriate 
Resource  Sponsor. 
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(2)  Outputs 

-  Modified  object  instance  to  database. 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  This  function  changes  all  EBILLET  data. 

(4)  Volume 

-  Unpredictable,  but  changes  rarely  occur. 

(5)  Frequency 

-  Once  per  year, 
c.  Delete  EBILLET  data 

(1)  Inputs 

-  List  of  billets  to  delete  from  OPNAV 
1000/2  or  Notification  Letter  from  the 
appropriate  Resource  Sponsor. 

-  EBILLET  object  instance  from  database. 

(2)  Outputs 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  Backup  of  existing  object  should  be  made 
prior  to  deletion. 

(4)  Volume 

-  Unpredictable,  but  deletions  rarely 
occur . 

(5)  Frequency 

-  Less  than  once  per  year. 
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3  .  OFFICER  Update  Mechanisms 

a.  Add  new  OFFICER  data 

(1)  Inputs 

-  List  of  new  officer  personnel  from  ODCR 
PCS  orders,  or  personnel  input  form  from 
the  Personnel  Office. 

(2)  Outputs 

-  New  OFFICER  object  instance  in  database 

(3)  Processing  notes 

-  Data  imported  enmasse  when  creating 
database . 

(4)  Volume 

-  10  to  500  billets  input  when  creating 
database . 

-  Five  to  200  per  year. 

(5)  Frequency 

-  Monthly, 

b.  Edit  data  in  OFFICER 
(1)  Inputs 

-  OFFICER  object  instance  from  database 
(including  OBILLET  properties). 

-  OFFICER  change  data  from  personnel  data 
change  form  from  the  Personnel  Office  or 
the  Executive  Officer. 
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(2)  Outputs 

-  Modified  object  instance  to  database. 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  This  function  changes  all  OFFICER  data. 

(4)  Volume 

-  Ten  officers  per  month. 

(5)  Frequency 

-  Monthly. 

c.  Delete  OFFICER  data 

(1)  Inputs 

-  List  of  personnel  to  delete  from  the 
check  out  sheets  received  from  the 
Department  Head. 

-  OFFICER  object  instance  from  database. 

(2)  Outputs 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  Backup  of  existing  object  should  be  made 
prior  to  deletion. 

(4)  Volume 

-  Zero  to  ten  per  month. 

(5)  Frequency 

-  Monthly. 

4.  ENLISTED  Update  Mechanisms 
a.  Add  new  ENLISTED  data 
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(1)  Inputs 

-  List  of  new  enlisted  personnel  from  EDVR 
and  PCS  orders. 

( 2 )  Outputs 

-  New  ENLISTED  object  instance  in  database. 

(3)  Processing  notes 

-  Data  imported  enmasse  when  creating 
database . 

(4)  Volume 

-  50  to  5000  billets  input  when  creating 
database . 

-  Ten  to  1500  per  year. 

(5)  Frequency 

-  Weekly. 

b.  Edit  data  in  ENLISTED 

(1)  Inputs 

-  ENLISTED  object  instance  from  database 
(including  EBILLET  properties). 

-  ENLISTED  change  data  from  personnel  data 
change  form  from  the  Personnel  Office  or 
the  Department  Head. 

(2)  Outputs 

-  Modified  object  instance  to  database. 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  This  function  changes  all  ENLISTED  data. 
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(4) 


Volume 


-  100  enlisted  personnel  per  month. 

(5)  Frequency 

-  Weekly. 

c.  Delete  ENLISTED  data 

(1)  Inputs 

-  List  of  personnel  to  delete  from  the 
check  out  sheets  received  from  the 
Department  Head. 

-  ENLISTED  object  instance  from  database. 

(2)  Outputs 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  Backup  of  existing  object  should  be  made 
prior  to  deletion. 

(4)  Volume 

-  Zero  to  100  per  month. 

(5)  Frequency 

-  Weekly. 

5.  DEPARTMENT  Update  Mechanisms 
a.  Add  new  DEPARTMENT  data 
(1)  Inputs 

-  New  DEPARTMENT  list  from  OPNAV  1000/2  or 
Notification  Letter  from  the  appropriate 
Resource  Sponsor. 
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(2)  Outputs 

-  New  DEPARTMENT  object  instance  in 
database . 

(3)  Processing  notes 

-  Data  imported  enmasse  when  creating 
database. 

(4)  Volume 

-  Four  to  ten  departments  input  when 
creating  database. 

-  Less  than  one  per  year. 

(5)  Frequency 

-  Less  than  annually, 
b.  Edit  data  in  DEPARTMENT 

(1)  Inputs 

-  DEPARTMENT  object  instance  from  database 
(including  DIVISION  properties). 

-  DEPARTMENT  change  data  from  OPNAV  1000/2 
or  Notification  Letter  from  the  appropriate 
Resource  Sponsor. 

(2)  Outputs 

-  Modified  object  instance  to  database. 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  This  function  changes  all  DEPARTMENT 
data . 
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(4) 


Volume 


-  Less  than  one  per  year. 

(5)  Frequency 

-  Less  than  annually, 
c.  Delete  DEPARTMENT  data 

(1)  Inputs 

-  List  of  departments  to  delete  from  OPNAV 
1000/2  or  Notification  Letter  from  the 
appropriate  Resource  Sponsor. 

-  DEPARTMENT  object  instance  from  database. 

(2)  Outputs 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  Backup  of  existing  object  should  be  made 
prior  to  deletion. 

(4)  Volume 

-  Less  than  one  per  year. 

(5)  Frequency 

-  Less  than  annually. 

6.  DIVISION  Update  Mechanisms 

a.  Add  new  DIVISION  data 
(1)  Inputs 

-  New  DIVISION  list  from  OPNAV  1000/2  or 
Notification  Letter  from  the  appropriate 
Resource  Sponsor. 
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(2)  Outputs 

-  New  DIVISION  object  instance  in  database. 

(3)  Processing  notes 

-  Data  imported  enmasse  when  creating 
database . 

(4)  Volume 

-  Five  to  50  divisions  input  when  creating 
database . 

-  Less  than  one  per  year. 

(5)  Frequency 

-  Less  than  annually, 
b.  Edit  data  in  DIVISION 

(1)  Inputs 

-  DIVISION  object  instance  from  database 
(including  OBILLET  and  EBILLET  properties). 

-  DIVISION  change  data  from  OPNAV  1000/2  or 
Notification  Letter  from  the  appropriate 
Resource  Sponsor. 

(2)  Outputs 

-  Modified  object  instance  to  database. 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  This  function  changes  all  DIVISION  data. 

(4)  Volume 

-  Less  than  one  per  year. 
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(5)  Frequency 

-  Less  than  annually, 
c.  Delete  DIVISION  data 

(1)  Inputs 

-  List  of  divisions  to  delete  from  OPNAV 
1000/2  or  Notification  Letter  from  the 
appropriate  Resource  Sponsor. 

-  DIVISION  object  instance  from  database. 

(2)  Outputs 

-  Confirmation  message  on  screen. 

(3)  Processing  notes 

-  Backup  of  existing  object  should  be  made 
prior  to  deletion. 

(4)  Volume 

-  Less  than  one  per  year. 

(5)  Frequency 

-  Less  than  annually. 

B.  DISPLAY  MECHANISMS 

1.  OFFICER  Display  Mechanisms 
a.  Query  on  OFFICER 

(1)  Output  Description 

-  Form  showing  all  data  for  an  Officer. 

(2)  Source  Data 

-  OFFICER  object. 
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-  DEPARTMENT  object. 

-  Officer  name  or  SSN  keyed  in  by  user. 

(3)  Processing  Notes. 

-  Used  by  manpower  analyst,  or  other 
authorized  user. 

(4)  Volume 

-  Five  per  week. 

(5)  Frequency 

-  Daily. 

b.  Officer  Manning  Report 

(1)  Output  Description 

-  Report  showing  Officer  billets  authorized 
and  the  Commissioned  Officers  assigned  to 
them. 

(2)  Source  Data 

-  OFFICER  object. 

-  DEPARTMENT  object. 

(3)  Processing  Notes. 

-  Report  produced  upon  request  from  user. 

(4)  Volume 

-  One  for  each  department  head,  including 
Executive  department. 

(5)  Frequency 

-  Monthly. 
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c.  Officer  Status  Report 

(1)  Output  Description 

-  Report  showing  Officer  billets  authorized 
and  the  number  of  personnel  assigned  to 
them. 

(2)  Source  Data 

-  OFFICER  object. 

-  DEPARTMENT  object. 

(3)  Processing  Notes. 

-  Report  produced  upon  request  from  user. 

(4)  Volume 

-  One  for  each  department  head,  including 
Executive  department. 

(5)  Frequency 

-  Monthly 

2.  ENLISTED  Display  Mechanisms 
a.  Query  on  ENLISTED 

(1)  Output  Description 

-  Form  showing  all  data  for  an  Enlisted 
member . 

(2)  Source  Data 

-  ENLISTED  object. 

-  DEPARTMENT  object. 

-  Enlisted  member's  name  or  SSN  keyed  in  by 
user . 
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(3)  Processing  Notes. 

-  Used  by  manpower  analyst,  or  other 
authorized  user. 

(4)  Volume 

-  Five  per  week  per  department. 

(5)  Frequency 

-  Daily. 

b.  Department/Division  Manning  Report 

(1)  Output  Description 

-  Report  showing  Enlisted  billets 
authorized  and  the  personnel  assigned  to 
them . 

(2)  Source  Data 

-  ENLISTED  object. 

-  DEPARTMENT  or  DIVISION  object. 

(3)  Processing  Notes. 

-  Report  produced  upon  request  from  user. 

(4)  Volume 

-  One  for  each  department  head,  including 
Executive  department. 

(5)  Frequency 

-  Monthly. 
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c.  Department/Division  Status  Report 

(1)  Output  Description 

-  Report  showing  Enlisted  billets 
authorized  and  the  number  of  personnel 
assigned  to  them. 

(2)  Source  Data 

-  ENLISTED  object. 

-  DEPARTMENT  or  DIVISION  object. 

(3)  Processing  Notes. 

-  Report  produced  upon  request  from  user. 

(4)  Volume 

-  One  for  each  department  head,  including 
Executive  department. 

(5)  Frequency 

-  Monthly 

3.  Combined  OFFICER/ENLISTED  Display  Mechanisms 
a.  Designator/Rating  Status  Report 

(1)  Output  Description 

-  Report  showing  the  quantity  of  billets 
authorized  by  designator  and  rating,  and 
the  number  of  personnel  assigned  within 
each. 

(2)  Source  Data 

-  OFFICER  object. 

-  ENLISTED  object. 

-  DEPARTMENT  or  DIVISION  object. 
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(3)  Processing  Notes. 

-  Report  produced  upon  request  from  user. 

(4)  Volume 

-  One  for  each  department,  including 
Executive  department. 

(5)  Frequency 

-  Monthly. 

b.  Paygrade  Status  Report 

(1)  Output  Description 

-  Report  showing  the  quantity  of  billets 
authorized  by  paygrade  and  the  number  of 
personnel  assigned  within  each  paygrade. 

(2)  Source  Data 

-  OFFICER  object. 

-  ENLISTED  object. 

-  DEPARTMENT  or  DIVISION  object. 

(3)  Processing  Notes. 

-  Report  produced  upon  request  from  user. 

(4)  Volume 

-  One  for  each  department  head,  including 
Executive  department. 

(5)  Frequency 

-  Monthly. 
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c.  Personnel  Gains/Losses  Report 


(1)  Output  Description 

-  Report  showing  the  personnel  ordered  to 
the  command  but  not  yet  received  and 
personnel  whose  PRD  is  within  three  months 
of  the  report  date. 

(2)  Source  Data 

-  OFFICER  object. 

-  ENLISTED  object. 

(3)  Processing  Notes. 

-  Report  produced  upon  request  from  user. 

(4)  Volume 

-  One  for  each  department  head,  including 
Executive  department. 

(5)  Frequency 

-  Monthly 

C.  CONTROL  MECHANISMS 

1.  System  Control  Mechanisms 

a.  Provide  password  system  to  ensure  that  only 
authorized  users  can  access  for  viewing, 
editing,  or  deleting  data. 

b.  Provide  verification  system  to  ensure  that  the 
authorized  users  have  the  opportunity  to  verify 
data  prior  to  an  instance  of  any  object  being 
stored  in  the  database. 
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c.  Provide  verification  system  to  ensure  that  the 
authorized  users  have  the  opportunity  to  verify 
data  prior  to  an  instance  of  any  object  being 
deleted  from  the  database. 

d.  Provide  security  controls  to  ensure  that  data  in 
the  database  cannot  be  altered  from  the  Reports 
application. 

2.  Object  Control  Mechanisms 

a.  Provide  a  set  of  tables  to  ensure  that  only 
authorized  data  values  for  Rating,  Rate, 
Paygrade,  PNEC/SNEC,  Grade,  Designator,  Billet 
Sequence  Code,  Department  and  Division  Name  are 
entered  into  data  fields  prior  to  an  instance  of 
an  object  being  stored  in  the  database. 

b.  Provide  verification  system  to  ensure  that 
mandatory  fields  have  values  entered  prior  to  an 
instance  of  an  object  being  stored  in  the 
database . 
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APPENDIX  H:  MENU  HIERARCHY 


BILLET  DATA  MENU 

1 .  Add  New  Billet 
2  Edit  ailel  Data 
3.  Delete  Billet  — 
4  Personnel  Data  Menu 
5.  Reports  Menu 
6  Return  to  Manpower 
Menu 


r 

PERSONNEL  DATA 

MENU 

1. 

Add  New  Personnel 

-  2. 

Edit  Personnel  Data 

3. 

Delete  Personnel 

4. 

Billet  Data  Menu 

5. 

Reports  Menu 

6. 

Return  to  Manpower 

1 

Meru 

MANPOWER  REPORTS 
MENU 

1.  Department 

2.  Division 

3.  Olficer 

4  Status  Reports  Menu 
S.  Manpower  Menu 
6  Return  to  Reports 
Merxi 


^BILLET  TYPE  MENU 

1.  Officer 

2.  Enlisted 

3.  Return  to  Billet  Data 

Menu 


BILLET  DISPLAY 
MENU 

1 .  By  Department 

2.  By  Division 

3.  By  BSC 

4.  Return  to  Billet  Data 

Menu 


RECORD  TYPE  MENU 

1.  Officer 
2  Enlisted 

3.  Return  to  Personnel 
Data  Menu 


Figure  H-1:  Menu  Tree 


WELCOME  TO 


AMA/PMS 

MAIN  MENU 


1 .  Manpower 

2.  Reports 

3.  Exit  to  OS 


Enter  the  number  of  your  selection 


Figure  H-2:  Main  Menu 
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AMA/PMS 


MANPOWER  MENU 


1 .  Billet  Data 

2.  Personnel  Data 

3.  Return  to  Main  Menu 


Enter  the  number  of  your  selection 


Figure  H-3:  Manpower  Menu 
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AMA/PMS 


REPORTS  MENU 

1 .  Gains/Losses  Report 

2.  Manpower  Report 

3.  Status  Report 

4.  Ad  Hoc  Queries 

5.  Return  to  Main  Menu 

Enter  the  number  of  your  selection _ 

Figure  H-4:  Reports  Menu 
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AMA/PMS 


BILLET  DATA  MENU 

1 .  Add  New  Billet 

2.  Edit  Billet  Data 

3.  Delete  Billet 

4.  Personnel  Data  Menu 

5.  Reports  Menu 

6.  Return  to  Manpower  Menu 


Enter  the  number  of  your  selection 


Figure  H-5:  Billet  Data  Menu 


AMA/PMS 


PERSONNEL  DATA  MENU 

1 .  Add  New  Personnel 

2.  Edit  Personnel  Data 

3.  Delete  Personnel 

4.  Billet  Data  Menu 

5.  Reports  Menu 

6.  Return  to  Manpower  Menu 

Enter  the  number  of  your  selection _ 

Figure  H-6:  Personnel  Data  Menu 


133 


AMA/PMS 


MANPOWER  REPORTS  MENU 

1 .  Department 

2.  Division 

3.  Officer 

4.  Status  Reports  Menu 

5.  Manpower  Menu 

6.  Return  to  Reports  Menu 


Enter  the  number  of  your  selection 


Figure  H-7 :  Manpower  Reports  Menu 
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AMA/PMS 


STATUS  REPORTS  MENU 

1 .  Department 

2.  Division 

3.  Designator  /  Rating 

4.  Grade/ Paygrade 

5.  Officer 

6.  Manpower  Reports  Menu 

7.  Manpower  Menu 

8.  Return  to  Reports  Menu 


Enter  the  number  of  your  selection 


Figure  H-8 :  Status  Reports  Menu 
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AMA/PMS 


BILLET  TYPE  MENU 


1 .  Officer 

2.  Enlisted 

3.  Return  to  Billet  Data  Menu 


Enter  the  number  of  your  selection 


Figure  H-9:  Billet  Type  Menu 
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AMA/PMS 


BILLET  DISPLAY  MENU 


1 .  By  Department 

2.  By  Division 

3.  By  BSC 

4.  Return  to  Billet  Data  Menu 


Enter  the  number  of  your  selection 


Figure  H-10:  Billet  Display  Menu 
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AMA/PMS 


RECORD  TYPE  MENU 


1 .  Officer 

2.  Enlisted 

3.  Return  to  Personnel  Data  Menu 


Enter  the  number  of  your  selection 


Figure  H-11;  Record  Type  Menu 
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APPENDIX  I:  MENU  LOGIC  (PSEUDO  CODE) 


A.  MAIN  MENU 
Begin  (*inodule*) 

Case  menu  choice  of: 

1:  Get  MANPOWER  MENU 

2:  Get  REPORTS  MENU 

End ( *module* ) 

B.  MANIOWER  MENU 
Begin  (*module*) 

Case  menu  choice  of: 


1:  Get  BILLET  DATA  MENU 

2:  Get  PERSONNEL  DATA  MENU 

3:  Get  MAIN  MENU 

End  (*module*) 

C,  REPORTS  MENU 

Begin  (*module*) 

Case  menu  choice  of : 

1:  Get  MANPOWER  REPORTS  MENU 

2:  Get  STATUS  REPORTS  MENU 

3:  Get  Gains/Losses  Report  (*procedure  call*) 

4:  Get  MAIN  MENU 

End  (*module*) 
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D.  BILLET  DATA  MENU 
Begin  (*inodule*) 

Case  menu  choice  of: 

1:  Get  BILLET  TYPE  MENU 

2:  Get  BILLET  DISPLAY  MENU 

3:  Get  BILLET  DISPLAY  MENU 

4:  Get  REPORTS  MENU 

5:  Get  MANPOWER  MENU 

End  (*module*) 

E.  PERSONNEL  DATA  MENU 

Begin  (*module*) 

Case  menu  choice  of: 

1;  Get  RECORD  TYPE  MENU 

2:  Get  Edit  Personnel  Data  (*procedure  call*) 

(*edit  function  handled  by  DBMS*) 

3:  Get  Delete  Personnel  Data  (*procedure  call*) 

(*delete  function  handled  by  DBMS*) 

4:  Get  REPORTS  MENU 

5;  Get  MANPOWER  MENU 
End  (*module*) 

F.  MANPOWER  REPORTS  MENU 
Begin  (*module*) 

Case  menu  choice  of: 

1:  Get  Department  Manning  Report  {*procedure 

call*) 

2:  Get  Division  Manning  Report  (*procedure  call*) 
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3:  Get  Officer  Manning  Report  (*procedure  call*) 

4:  Get  MAIN  MENU 

5:  Get  REPORTS  MENU 

End  (*module*) 

G.  STATUS  REPORTS  MENU 
Begin  (*inodule*) 

Case  menu  choice  of: 

1:  Get  Department  Status  Report  ( *procedure 

call*) 

2:  Get  Division  Status  Report  (*procedure  call*) 

3:  Get  Designator/Rate  Status  Report  (*procedure 

call* ) 

4:  Get  Paygrade  Status  Report  (*procedure  call*) 

5:  Get  Officer  Status  Report  (*procedure  call*) 

6:  Get  MANPOWER  MENU 

7:  Get  REPORTS  MENU 

End  (*module*) 

H.  BILLET  TYPE  MENU 
Begin  (*module*) 

Case  menu  choice  of : 

1:  Get  Add  Officer  Billet  (*procedure  call*) 

(*add  function  handled  by  DBMS*) 

2:  Get  Add  Enlisted  Billet  (*procedure  call*) 

(*add  function  handled  by  DBMS*) 

3:  Get  BILLET  DATA  MENU 

End  (*module*) 
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I.  BILLET  DISPLAY  MENU 

Begin  (*inodule*)  (*display  function  handled  by  DBMS*) 
Case  menu  choice  of: 

1:  Get  Display  Department  Billets  (*procedure 

call*) 

2:  Get  Display  Division  Billets  (*procedure 

call*) 

3:  Get  Display  Billet  By  BSC  (*procedure  call*) 

4:  Get  BILLET  DISPLAY  MENU 

End  (*module*) 

J.  RECORD  TYPE  MENU 
Begin  (*module*) 

Case  menu  choice  of: 

1:  Get  New  Officer  Record  (*procedure  call*) 

2:  Get  New  Enlisted  Record  (*procedure  call*) 

3:  Get  PERSONNEL  DATA  MENU 

End  (*module*) 

K.  REPORT  GENERATION  PROCEDURES 

1.  Department/Division  Manning  Report 

a.  Display  data  by  Department  then  by  Division. 

b.  Records/Fields  used: 

1)  EBILLET/BSC,  Billet  Title,  BA,  Rate,  PNEC, 
SNEC,  DName,  DivName 

2)  ENLISTED/BSC,  Name,  Rate,  PNEC,  SNEC,  PRD, 
EAOS 

c.  Sort  EBILLET  records  by  DName .  DivName. 
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d.  For  each  BSC  in  EBILLET,  compare  and  match 
ENLISTED  records  to  EBILLET  records  by  keying  on 
BSC. 

e.  Print  data  per  report  format  in  Appendix  D. 

2.  Department/Division  Status  Report 

a.  Display  data  by  Department  then  by  Division. 

b.  Records/Fields  used: 

1)  EBILLET/BSC,  Billet  Title,  BA  Rate,  PNEC, 
SNEC,  DName,  DivName 

2)  ENLISTED/BSC,  PRD,  EAOS 

c.  Sort  EBILLET  records  by  DName .  DivName . 

d.  For  each  BSC  in  EBILLET,  compare  and  match 
ENLISTED  records  to  EBILLET  records  by  keying  on 
BSC. 

f.  Using  ENLISTED  records  calculate  number  of 
personnel  on  board  for  each  BSC  for  the  current 
month  and  for  each  of  the  next  four  (4)  months. 

(For  each  BSC  in  ENLISTED  record,  if  EAOS  <  PRD.  use 
EAOS  to  determine  projected  on  board;  else  use  PRD.) 

g.  Print  data  per  report  format  in  Appendix  D. 

3.  Officer  Manning  Report 

a.  Display  data  by  Department  then  by  Division. 

b.  Records/Fields  used: 

1)  OBILLET/BSC,  Billet  Title,  BA,  Grade, 
Designator,  DName,  DivName 

2)  OFFICER/BSC,  Name,  Grade,  Designator,  PRD 
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c.  Sort  OBILLET  records  by  DNaine .  DivName . 

d.  For  each  BSC  in  OBILLET,  compare  and  match 
OFFICER  records  to  OBILLET  records  by  keying  on  BSC. 

e.  Print  data  per  report  format  in  Appendix  D. 

4.  Officer  Status  Report 

a.  Display  data  by  Department  then  by  Division. 

b.  Records/Fields  used: 

1)  OBILLET/BSC,  Billet  Title,  Grade,  Designator, 
BA,  DName,  DivName 

2)  OFFICER/BSC,  PRD 

c.  Sort  records  on  BSC. 

d.  For  each  BSC  in  OBILLET,  determine  the  number  of 
OFFICERS  assigned  against  it  for  current  month  and 
each  of  the  next  four  (4)  months. 

e.  Print  data  per  report  format  in  Appendix  D. 

5.  Grade/Paygrade  Status  Report 

a.  Records/Fields  used: 

1)  OBILLET/Grade,  BA 

2)  OFFICER/Grade,  PRD 

3)  EBILLET/Paygrade,  BA 

4)  ENLISTED/Paygrade,  PRD,  EAOS 

b.  Sort  OBILLET  and  OFFICER  records  on  Grade. 

c.  Sort  EBILLET  and  ENLISTED  records  on  Paygrade. 

d.  Calculate  -  OFFICER  PAYGRADE  STATUS  REPORT 

1)  Using  OBILLET  records,  count  number  of  ^  for 
each  Grade . 
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2)  Using  OFFICER  records,  count  number  of  each 
Grade  currently  assigned. 

3)  Calculate  percent  of  BA  currently  filled  for 
each  Grade  (COB/BA) . 

4)  Using  the  PRD  field  of  OFFICER  record, 
calculate  the  number  of  each  Grade  on  board  for 
the  current  month  and  for  each  of  the  next  seven 
(7)  months. 

e.  Calculate  -  ENLISTED  PAYGRADE  STATUS  REPORT 

1)  Using  EBILLET  records,  count  number  of  BA  for 
each  Pavarade. 

2)  Using  ENLISTED  records,  count  number  of  each 
Pavarade  currently  assigned. 

3)  Calculate  percent  of  BA  currently  filled  for 
each  Pavarade  (COB/BA) . 

4)  Using  the  PRD  or  EAOS  field  of  ENLISTED 
record,  calculate  the  number  of  each  Pavarade  on 
board  for  the  current  month  and  for  each  of  the 
next  seven  (7)  months.  (For  each  ENLISTED 
record,  if  EAOS  <  PRD.  use  EAOS  to  determine 
projected  on  board;  else  use  PRD . 

f.  Print  data  per  report  format  in  Appendix  D. 

6.  Designator/Rating  Status  Report 

a.  Display  data  by  Designator  and  Rating 

b.  Records/Fields  used: 

1)  OBILLET/Grade,  BA,  Designator 
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2)  OFFICER/Grade,  Designator 

3)  EBILLET/BA,  PNEC,  SNEC,  Rating,  Paygrade 

4)  ENLISTED/PNEC,  Rate 

c.  Sort  OBILLET  and  OFFICER  records  on  Designator. 

d.  Sort  EBILLET  and  ENLISTED  records  on  Rate,  then 
by  PNEC  (if  one  is  assigned). 

e.  Calculate  -  DESIGNATOR  STATUS  REPORT 

1)  Using  OBILLET  records:  For  each  Designator  in 
OBILLET,  count  number  of  BA  in  each  Grade . 

2)  Using  OFFICER  records:  For  each  Designator  in 
OFFICER,  count  number  of  personnel  on  board  in 
each  Grade . 

f.  Calculate  -  RATING  STATUS  REPORT 

1)  Using  EBILLET  records: 

a)  For  each  Rating  in  EBILLET,  count  number 
of  BA  for  each  Paygrade . 

b)  Subdivide  each  Rating  by  PNEC  if  one  is 
assigned . 

2)  Using  ENLISTED  records: 

a)  For  each  Rate  in  ENLISTED,  count  number 
of  personnel  currently  on  board. 

b)  Subdivide  each  Rate  by  PNEC  if  one  is 
assigned. 

g.  Print  data  per  report  format  in  Appendix  D. 
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7.  Gains/Losses  Report 


a.  Records/Fields  used: 

1)  OFFICER/Name,  Grade,  Designator,  PRD 

2)  ENLISTED/Name,  Rate,  PNEC,  PRD,  EAOS 

b.  Sort  records  by  PRD. 

c.  Calculate  -  GAINS  REPORT 

1)  Using  OFFICER  and  ENLISTED  records,  identify 
those  personnel  who  will  be  arriviiig  at  the 
activity  within  the  next  six  (6)  months.  (This 
date  will  be  reflected  in  the  PRD  field  with  an 
"A"  as  the  first  digit.) 
d)  Calculate  -  LOSSES  REPORT 

1)  Using  OFFICER  and  ENLISTED  records,  identify 
those  personnel  who  will  be  departing  the 
activity  within  the  next  six  (6)  months.  (For 
each  ENLISTED  record,  if  EAOS  <  PRD,  use  EAOS  to 
determine  projected  on  board;  else  use  PRD.) 
e.  Print  data  per  report  format  in  Appendix  D. 
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